Cloud-init bi-weekly status

Posted on Tue 16 June 2020 in status-meeting-minutes • 6 min read

Meeting information

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.

community charter

The discussion about "community charter" started at 16:54.

Office Hours (~next 30 minutes)

The discussion about "Office Hours (~next 30 minutes)" started at 16:59.

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 <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

Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)