== Meeting information == * #cloud-init: cloud-init status meeting, 16 Jun at 16:21 — 17:58 UTC * Full logs at [[http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-06-16-16.21.log.html]] == Meeting summary == ''LINK:'' https://cloud-init.github.io/ === Recent Changes === The discussion about "Recent Changes" started at 16:24. === In-progress Development === The discussion about "In-progress Development" started at 16:32. * ''LINK:'' https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018 * ''LINK:'' * ''LINK:'' https://github.com/canonical/cloud-init/pull/391 * ''LINK:'' https://github.com/canonical/cloud-init/pull/416#issuecomment-640032968 * ''ACTION:'' file feature bug about refactoring startup services * ''ACTION:'' mailing list email requesting comment/concerns about a refactor of startup services === community charter === The discussion about "community charter" started at 16:54. * ''LINK:'' https://bugs.launchpad.net/cloud-init/?field.tag=bitezise === Office Hours (~next 30 minutes) === The discussion about "Office Hours (~next 30 minutes)" started at 16:59. * ''LINK:'' https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_puppet.py#L106 could this be entirely puppet specific, and no other module does this dance? * ''LINK:'' https://github.com/canonical/cloud-init/blob/master/cloudinit/reporting/events.py#L84 * ''LINK:'' https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_rsyslog.py#L210 one more == Vote results == == Done items == * (none) == People present (lines said) == * blackboxsw (61) * meena (6) * meetingology (6) * AnhVoMSFT (2) * ubot5 (1) * cyberpear (1) * Odd_Bloke (1) * smoser (0) * rharper (0) == Full Log == 16:21 #startmeeting cloud-init status meeting 16:21 Meeting started Tue Jun 16 16:21:42 2020 UTC. The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 16:21 16:21 Available commands: action commands idea info link nick 16:22 #chair smoser Odd_Bloke rharper 16:22 Current chairs: Odd_Bloke blackboxsw rharper smoser 16:22 Welcome to the bi-weekly cloud-init status meeting. A place to chat about upstream cloud-init activity/ 16:23 his meeting is a welcome place for interruptions, questions, requests and unrelated discussions at any point. 16:23 *this* 16:23 previous meeting minutes are stored on github 16:23 #link https://cloud-init.github.io/ 16:24 The topics we generally cover in this meeting are the following: Previous Actions, Recent Changes, In-progress Development, Community Charter, Office Hours (~30 mins). 16:24 From the previous meeting we captured no actions, so I'll jump into the next topic 16:24 #topic Recent Changes 16:25 the following are commits merged into cloud-init's upstream master branch: https://paste.ubuntu.com/p/WdsZXbwwWd/ 16:26 found via git log --since 06-02-2020 16:29 notable changes: util.runparts and subp out of util into subp.py, there are a couple of branches related to improved vmware support, and resolving keyerror issues for users providing network configuration with bridges. 16:30 also upstream travis CI is now using the commercial travis-ci.com instead of travis-ci-org which should give us better throughput on test runs. 16:31 community notice: if any PRs created > 1 week ago have problems with unresolved travis ci runs marked 'in progress' those PRs will likely need to be closed and re-submitted due to the shift in travis-ci endpoints. 16:32 #topic In-progress Development 16:33 Upstream devs are currently working our way through Ubuntu StableReleaseUpdate (SRU) validation to release cloud-init version 20.2.45 to Ubuntu Xenial, Bionic, Eoan and Focal. Thanks falcojr lucasmoura and Odd_Bloke for all the help generating test cases and reviewing SRU-related content. 16:34 We are about halfway through out testing of this release of cloud-init and expect to be able to wrap this up before next week. 16:34 To track this release, anyone can subscribe to the SRU process bug 16:35 #link https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018 16:35 Ubuntu bug 1881018 in cloud-init (Ubuntu) "sru cloud-init (19.4.33 to 20.2-45) Xenial, Bionic, Eoan and Focal" [Undecided,In progress] 16:35 that bug will go to Fix Released when our upload to -updates apt pocket is published 16:36 Beyond SRU, there is a significant refactor of cloudinit.net* module to define a clear API and push distro-specific content into the distro modules. 16:37 #link 16:37 #link https://github.com/canonical/cloud-init/pull/391 16:38 Thanks Odd_Bloke for driving that refactor. Those interested should check out the above PR 16:39 I think that about wraps it. 16:40 during the util.subp refactor i suggested also looking into centralising service enabling and (re) starting 16:41 but we kinda glossed over that because of the net refactor 16:41 meena: good chance to bring that up: let's get that comment link 16:43 #link https://github.com/canonical/cloud-init/pull/416#issuecomment-640032968 16:44 meena: your comment was really about re-organizing the ./systemd ./upstart top-level directories and refactoring down into the distros somehow? 16:44 as that startup service construct is highly distro dependent? 16:46 If that's the suggestion you are raising for comment, I think it sounds like a reasonable thing to consider. Each distro has it's own way of handling system service management. 16:47 *nod 16:48 given the fact that all the systemd/ startup script files are all templates, it indicates that we have a lot of distro-specific uniqueness even across various flavors of linux 16:49 I think that refactor would be significantly simpler to describe in a distro-level API 16:51 meena: maybe we file a feature bug against cloud-init so we can prioritize that work. 16:51 you're right. let's do that 16:52 we could surface that bug to the mailinglist 16:53 meena: do you want to do either of those (bug or mailinglist email: subj: Refactor startup service to distro-specific Api) ? 16:53 #action file feature bug about refactoring startup services 16:53 * meetingology file feature bug about refactoring startup services 16:53 #action mailing list email requesting comment/concerns about a refactor of startup services 16:53 * meetingology mailing list email requesting comment/concerns about a refactor of startup services 16:54 I've added actions that we can track by next meeting to see if we can make progress on that discussion 16:54 ok next topic I think 16:54 #topic community charter 16:55 As always, any aspects of the cloud-init project is open for participation from community members. 16:56 We thank everyone for contributing bugs @ https://bugs.launchpad.net/cloud-init/+filebug, reviewing open 'New' bugs that are filed, and reviewing pulls requests @ https://github.com/canonical/cloud-init/pulls 16:57 all reviews are welcome on any PRs that are up. and driving feature discussions are also encouraged. Thanks meena for participating on all of those fronts 16:59 for those just wanting to join in and contribute small pull requests there is a queue of bugs or features that should be a fairly contained set of tasks in our bitesize queue: 16:59 #link https://bugs.launchpad.net/cloud-init/?field.tag=bitezise 16:59 #topic Office Hours (~next 30 minutes) 17:00 This 'section' of the meeting is a time where a couple of upstream devs will be available in channel for any discussions, questions, bug work or PR reviews. 17:01 In the absence of discussion topics, reviewing the active PRs generally occurs to scrub our queue and unblock conversations. 17:02 * blackboxsw addresses some review comments on a CI Ubuntu daily test branch 17:22 question: is there anyway to only target a particular reporting handler? 17:23 Right now the Azure DS emits events to the HyperV KVP handler and they also pass through the log handler. For the most part this is fine (and useful). For some larger event message (like compressed log), it does not make sense to emit a large blob of compressed gzip + b64 to the log, is it possible to skip the log handler ? 17:30 hrm, good question AnhVoMSFT . looking 17:33 blackboxsw: meena: Note that the service files are selected at package generation time, not at runtime, so it's not entirely clear to me how you would integrate them into the Distro hierarchy. 17:42 nice suggestion Odd_Bloke 17:43 AnhVoMSFT: I'm not seeing any filtering config options in reporting: config for handlers. Are you saying you are looking to add compressed object writes to your kvp message message plane? 17:44 * cyberpear wondering if there's any collaboration with the ignition folks 17:46 AnhVoMSFT: I think it's be reasonable to provide a named report handler to ReportEventStack 17:46 and let ReportEventStack limit what handlers it can emit publish_event to 17:48 https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_puppet.py#L106 could this be entirely puppet specific, and no other module does this dance? 17:50 AnhVoMSFT: that'd mean I suppose that report_event would need to accept a new param to limit which handler it calls handler.publish_event for 17:50 https://github.com/canonical/cloud-init/blob/master/cloudinit/reporting/events.py#L84 17:52 https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_rsyslog.py#L210 one more 17:52 or maybe you are suggesting that we add the ability for an existing handler to define a set of data types that it accepts (and will silently ignore others)? 17:54 and here meena https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_fan.py#L55-L83 17:58 ok I've got to run. time to close the meeting for today. Thanks all for joining in! 17:58 #endmeeting Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)