Skip to content

MinutesApr17th20

Jump to bottom Edit New page
Florian Forster edited this page Nov 26, 2023 · 1 revision

Attendees: Krzysztof, Dago, Sunku, Matthias, Jabir, Michal, Kamil, Florian, Kinga

Meeting minutes: Went through following issues in today's call:

  • 1. Enable collection of Prepared_stmt_count #3287
    • - One person have volunteered to help in the comments
    • - We should close if no one responds based on the labeling scheme
  • 2. Feedback Requested: Collectd Release Process Proposal #3223
    • - Sunku to clean up release process proposal doc, rename it to community engagement
    • - To cross reference comments from this to already discussed items at the Munich meetup
    • - Will publish the update on mailing list
  • 3. [WiP] linux_delay plugin: New plugin for Linux delay accounting. #3073
    • - Interested folks could add on mentioned features
    • - Open for anyone to take it up
  • 4. collectd memory: huge pages counted as used #2914
  • 5. No internal queueing anymore when all write plugins fail? #1543
    • - This is a fairly common issue that is noticed
    • - From collectd point of view we could only retry latest set of data, while still blowing away lot of metrics
    • - Alternative is to reimplementing queue logic in most of write plugins
    • - Alternative would be that write plugin could send success/fail of each metric they write and then drop, but this is a bit complex to implement
    • - From storage of metrics perspective, storage engine could drop the metric that was received twice
    • - We might need to figure out which write plugins successfully wrote the metrics out and then have collectd drop the metrics. Just because write plugins buffer the metrics doesn’t mean not all of them wrote successfully
    • - If anyone wants to work on this, need to write a design document first, there are many corner cases that we could miss if we start thinking about this
    • - We can ask/learn a bit more about the setup. If it’s a client-server setup, the internal queues might overflow within certain mins if the backend is not reasonable. If the client is sending across network and network have issues, then client can save these metrics until network issue has been restored with available memory in the client
    • - So based on most common usecases, we can address 80% of the problem usecases.
    • - Related issues are listed, need to study more

How do we figure out issues for 5.12 release

  • - Grooming for open source communities is different from grooming for a company project. We cant escalate if an assignee cant do the work.
  • - If the issues make it into master by freeze date, they will make it to next release, otherwise they don’t
  • - Some people walk away after opening the issues while some won't have anyone volunteering to review
  • - For issues like 3287 -> we can mention if someone is interested in doing community work but not sure about C programming, we can mention we can walk them through the code if they submit a pull request
  • - If someone wants their work to be included in the release, they need to volunteer their time in ensure the PR goes through the review and gets accepted in to master

Next call:

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

Please send out any agenda items you wish to cover in the call. The following items are planned to be covered in the next call:

Next Release: 5.12

  • Freeze date: Aug 1st
  • Release date: Aug 15th
Add a custom footer
Add a custom sidebar
Clone this wiki locally