Minutes from 2020-06-22

From collectd Wiki
Revision as of 03:04, 24 June 2020 by Sranganath (talk | contribs) (Created page with "'''Attendees:''' Nikolay, Octo, Matthias, sunku, Jabir == Derivative metrics via Collectd Plugins == * Calculating derivative metrics via co...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Attendees: Nikolay, Octo, Matthias, sunku, Jabir

Derivative metrics via Collectd Plugins

  • Calculating derivative metrics via collectd plugins is easier to do within read plugin, if it can be done
  • Dealing with metrics after we submit to daemon would be trickier
  • Ex: aggregation plugin provides some reference for label based metrics, we would need to invest some time to improve aggregation plugin & related code. Need to look into how best aggregation plugins would need to behave
  • For example consider 10 CPUs for which the metrics need to be read from, read plugins don’t register the metrics per CPU basis, when 2 of CPUs go offline we don’t know which metrics we are supposed to have. Do we want graph showing data not available or show only the ones available? Need to consider various aggregation models
  • Prometheus is really good in aggregating, assuming view that data presented to Prometheus has been updated atomically, you can essentially do math on these metrics for consistent result.
  • Need to consider various models available out there to see how best Collectd can build on it
  • With version 6 coming, we need to revisit fundamental way of how we deal with issues

Python plugin repo structure & contributions

  • Licensing questions have been there from the beginning of Collectd with bunch of GPL code in the daemon with argument that if we link plugins, export of the symbols of daemon & plugins should also be GPL. So daemon was changed to MIT as its not copy left. Since no plugin bits are linked into daemon so there is no derived work at direct compile time
  • Python plugins are one more step removed from the daemon, as it essentially starts python interpreter and it loads python plugins. So its fine to have MIT for daemon & python plugins. Its also ok to have python plugins to have GPL
  • GPL spreads into everything it touches (includes dynamic linking), just to be aware
  • If you want to add GPL python plugins, ideally a README should be added about licenses if its different than the repo license
  • For ISC - it falls under one of permissive licenses, it shields authors from any liabilities/damages. Its saying do whatever with code as long as you keep corporate notice.
  • Octo is open to changing it to MIT, but believes it wont make any difference
  • Plugins could have any license as long as they provide their own
  • Directory structure:
    • A sperate directory for each plugin would be good
    • As we might have different licenses for different plugins having separate directories would be great
    • There was a bug with function names clashed in python plugins, keep in mind going ahead: https://github.com/collectd/collectd/issues/3240
      • Probably due to global symbol resolution
      • Authors of python plugins be aware of this
      • If anyone wants to improve python plugin frameowkr, octo could help contact SVEN/SET
      • Thanks Matthias for sharing this
  • Provide a readme about the plugin & any assumptions
  • Happy to discuss as more questions as they arise