MinutesApr3rd20

Attendees: Sunku, Florian, Michal, KK, Nikolay, Jabir, Kamil, Robert, Emma Foley, Borja, Kinga

• • Thanks for great discussion

Agenda:

• • Go based plugin
  • Summary of 5.11 collectd release
  • Grooming session approach

Go based plugins for Collectd:

• Go code compiled into shared object and loaded in to Collectd
• Works for simple cases, atleast one bug value list with more than 4 or more values it seg faults, yet to see why
  • Not very stable: https://github.com/collectd/go-collectd/issues/26
  • Yet to figure out if this is official way
• Few other ways to use go and collectd together apart shared object approach
  • Go code has well tested implementation of binary protocol, like network plugin to hand metrics to daemon
  • There is implementation of ascii protocol to relatively eeasily write exec plugin in go rather than using existing exec plugin
  • There is also parsing for the plain text protocol to hook it go code to unix socket to handover metrics that way
  • Bunch of ways to get metrics other than shared object but require some other binary running. It can be fully external, to instrument app to send metrics to collectd. ** * Have separate binary such as exec plugin
  • If having metrics end point with http endpoint, as curl for example

Thanks to release managers for 5.11 release: Krzysztof Kepka, Matthias Runge, Florian Forster

• For 5.12 release:
  • An issue in changelog creation process, not all fixes were captured with the query, need to be updated to better help in 5.12
  • Could create a 5.11.1 release with all the changes correctly captured in changelog, at earliest possible so that delta from 5.11 wont be too much
  • 5.12 would be mid-august
  • Look in to another meetup after 5.12 meetup. Based on the travel situation we can figure out when is the best time

Collectd version support -> at this time its only last 2 releases. However not everyone in production might get to update at Collectd's cadence. Do we want to provide LTS release?

• • Majority use pre-package version of collectd, debian/Red Hat repos
  • Its up to responsibility of deb maintianers to apply security fixes, any major bug fixes
  • If users need very recent version of collectd than packages, they are responsible for updating themselves
  • If someone feels differently strongly would like to hear more
  • Idea is newer version is backward compatible to older versions. In theory update the version and don’t change anything in production. If any major interfaces need to be changed in newer version it would be considered as a bug

Most of the issues are from 5.8/5.9 which arent supported anymore

• We shouldnt close issue just because version is not supported anymore
• however before debug we should check the issue in latest version and see if it still persists
• If the submitters don’t respond to questions on the issue after it being tested, its ok to close those issues

Expose metadata from write plugin perspective:

• Write_http plugin does
• Network plugin doesnt

Grooming process:

• Do the attendees believe in value of grooming/bug-triage?
• Ultimate goal is to reduce the number of open issues
• It helps prioritize the issues for next release, people could bring up issues in the call to help address them for the next release
• Going through all the backlog would be really difficult in the call, rather its better for people to bring up the issues
• To help bring closure to open issues, would offline grooming help? How do we prioritize the issues?
• It might help to setup a milestone (called backlog) for the next release and assign issues to that milestone so those could be addressed
• The issues could be brought up in the call, made a case for next milestone so they could be addressed, however its difficult for everyone across the world to attend the call and share their priorities
• Issues that are related to existing plugin are much more easier to address than completely new plugins. So not all PRs are equal
• The question is to figure out what issues go to next release
  • Past: So far cut the release on a particular date based on availability
  • Problem with blocking a release based on a PR is there is no control over how PR could take shape
• In conclusion of discussion above:
  • We could focus on complex issues in the call, if the issues require high speed in person communication. Most issues could be discussed/prioritized/solved via github
  • Kinga could suggest few issues for the next call to be discussed/address, would be great if volunteers could do some preparation for those issues

Next call:

• • April 17th 2020 at 2:00 PM Friday, Coordinated Universal Time (UTC)/7AM Pacific Time
  • Webex link sent via collectd mailing list