16:21 <blackboxsw> #startmeeting cloud-init status meeting
16:21 <meetingology> 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 <meetingology> 
16:21 <meetingology> Available commands: action commands idea info link nick
16:22 <blackboxsw> #chair smoser Odd_Bloke rharper
16:22 <meetingology> Current chairs: Odd_Bloke blackboxsw rharper smoser
16:22 <blackboxsw> Welcome to the bi-weekly cloud-init status meeting. A place to chat about upstream cloud-init activity/
16:23 <blackboxsw> his meeting is a welcome place for interruptions, questions, requests and unrelated discussions at any point.
16:23 <blackboxsw> *this*
16:23 <blackboxsw> previous meeting minutes are stored on github
16:23 <blackboxsw> #link https://cloud-init.github.io/
16:24 <blackboxsw> 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 <blackboxsw> From the previous meeting we captured no actions, so I'll jump into the next topic
16:24 <blackboxsw> #topic Recent Changes
16:25 <blackboxsw> the following are commits merged into cloud-init's upstream master branch: https://paste.ubuntu.com/p/WdsZXbwwWd/
16:26 <blackboxsw> found via git log --since 06-02-2020
16:29 <blackboxsw> 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 <blackboxsw> 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 <blackboxsw> 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 <blackboxsw> #topic In-progress Development
16:33 <blackboxsw> 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 <blackboxsw> 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 <blackboxsw> To track this release, anyone can subscribe to the SRU process bug
16:35 <blackboxsw> #link https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018
16:35 <ubot5> 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 <blackboxsw> that bug will go to Fix Released when our upload to <ubuntu-release>-updates apt pocket is published
16:36 <blackboxsw> 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 <blackboxsw> #link
16:37 <blackboxsw> #link https://github.com/canonical/cloud-init/pull/391
16:38 <blackboxsw> Thanks Odd_Bloke for driving that refactor. Those interested should check out the above PR
16:39 <blackboxsw> I think that about wraps it.
16:40 <meena> during the util.subp refactor i suggested also looking into centralising service enabling and (re) starting
16:41 <meena> but we kinda glossed over that because of the net refactor
16:41 <blackboxsw> meena: good chance to bring that up: let's get that comment link
16:43 <blackboxsw> #link https://github.com/canonical/cloud-init/pull/416#issuecomment-640032968
16:44 <blackboxsw> meena: your comment was really about re-organizing the ./systemd ./upstart top-level directories and refactoring down into the distros somehow?
16:44 <blackboxsw> as that startup service construct is highly distro dependent?
16:46 <blackboxsw> 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 <meena> *nod
16:48 <blackboxsw> 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 <blackboxsw> I think that refactor would be significantly simpler to describe in a distro-level API
16:51 <blackboxsw> meena: maybe we file a feature bug against cloud-init so we can prioritize that work.
16:51 <meena> you're right. let's do that
16:52 <blackboxsw> we could surface that bug to the mailinglist
16:53 <blackboxsw> meena: do you want to do either of those (bug or mailinglist email: subj: Refactor startup service to distro-specific Api) ?
16:53 <blackboxsw> #action file feature bug about refactoring startup services
16:53 * meetingology file feature bug about refactoring startup services
16:53 <blackboxsw> #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 <blackboxsw> I've added actions that we can track by next meeting to see if we can make progress on that discussion
16:54 <blackboxsw> ok next topic I think
16:54 <blackboxsw> #topic community charter
16:55 <blackboxsw> As always, any aspects of the cloud-init project is open for participation from community members.
16:56 <blackboxsw> 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 <blackboxsw> 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 <blackboxsw> 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 <blackboxsw> #link https://bugs.launchpad.net/cloud-init/?field.tag=bitezise
16:59 <blackboxsw> #topic Office Hours (~next 30 minutes)
17:00 <blackboxsw> 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 <blackboxsw> 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 <AnhVoMSFT> question: is there anyway to only target a particular reporting handler?
17:23 <AnhVoMSFT> 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 <blackboxsw> hrm, good question AnhVoMSFT . looking
17:33 <Odd_Bloke> 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 <blackboxsw> nice suggestion Odd_Bloke
17:43 <blackboxsw> 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 <blackboxsw> AnhVoMSFT: I think it's be reasonable to provide a named report handler to ReportEventStack
17:46 <blackboxsw> and let ReportEventStack limit what handlers it can emit publish_event to
17:48 <meena> 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 <blackboxsw> 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 <blackboxsw> https://github.com/canonical/cloud-init/blob/master/cloudinit/reporting/events.py#L84
17:52 <meena> https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_rsyslog.py#L210 one more
17:52 <blackboxsw> 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 <blackboxsw> and here meena https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_fan.py#L55-L83
17:58 <blackboxsw> ok I've got to run.   time to close the meeting for today. Thanks all for joining in!
17:58 <blackboxsw> #endmeeting