16:18 <blackboxsw> #startmeeting cloud-init status meeting
16:18 <meetingology> Meeting started Tue May 19 16:18:05 2020 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
16:18 <meetingology> 
16:18 <meetingology> Available commands: action commands idea info link nick
16:18 <blackboxsw> #chair Odd_Bloke smoser rharper
16:18 <meetingology> Current chairs: Odd_Bloke blackboxsw rharper smoser
16:18 <blackboxsw> hello cloud-init, welcome to another round cloud-init status updates
16:19 <blackboxsw> our IRC channel topic carries the next planned status meeting for those that wish to participate. All are welcome to interject or drive converstation topics here
16:19 <blackboxsw> Previous meeting notes are here
16:19 <blackboxsw> #link https://cloud-init.github.io/status-2020-05-05.html#status-2020-05-05
16:19 <blackboxsw> and next status meeting should be in 2 weeks time.
16:20 <blackboxsw> looks like June 2. I'll set the topic of this irc channel to so that dropins can see a reminder for when that meeting is held
16:20 <blackboxsw> #topic #cloud-init pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting June 16:15 UTC | 20.1 (Feb 18) | 20.2 (Apr 28) | https://bugs.launchpad.net/cloud-init/+filebug
16:20 <blackboxsw> #topic #cloud-init pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting June 2 16:15 UTC | 20.1 (Feb 18) | 20.2 (Apr 28) | https://bugs.launchpad.net/cloud-init/+filebug
16:20 <blackboxsw> let's try that instead
16:21 <blackboxsw> The topics we generally cover in this meeting are the following: Previous Actions, Recent Changes, In-progress Development, Community Charter and Office Hours (~30 mins).
16:21 <blackboxsw> I'll jump through each topic, as always interjections, questions or other topics welcome
16:21 <blackboxsw> #topic Previous Actions
16:22 <blackboxsw> Nothing brought up as an action in the last meeting so we'll jump to the next topic
16:22 <blackboxsw> #topic Recent Changes
16:24 <blackboxsw> The following changes have landed in master; found via git log --since 05-05-2020 https://paste.ubuntu.com/p/d2qR8pTZNY/
16:26 <blackboxsw> there are a number of commits landed related to dropping additional py2 support from various paths as well as improving pytest fixtures   (thx OddBloke)  and some json schema definitions added to cc_snap and cc_apt_configure thanks lucasmoura
16:27 <blackboxsw> and an additional bit of work from meena to make libc discovery platform independent
16:27 <blackboxsw> #topic In-progress Development
16:30 <blackboxsw> Current themes of work for upstream include: continuing to refine a spec on cloud-init daemon mode and hot-plug support, purging python2-isms, improving pytest automation.
16:33 <blackboxsw> falcojr: also has a new approach for feature flag definitions/behavior in cloud-init  in https://github.com/canonical/cloud-init/pull/367  This should give us the ability to better codify upstream unconfiguraable cloud-init behavior which may differ on previous releases.
16:34 <blackboxsw> falcojr: Odd_Bloke & smoser thanks for good design discussion there. anyone interested feel free to weigh in.
16:36 <blackboxsw> Also in-progress work is a cloud-init StableReleaseUpdate planned to publish cloud-init version 20.2 to xenial, bionic, eoan and focal.
16:37 <blackboxsw> This will publish latest cloud-init (after verification) to old stable releases
16:38 <blackboxsw> the first step before SRU is to upload latest cloud-init to Ubuntu Groovy(20.10). Once this upload is complete, we'll start the SRU process to publish to Xenial, Bionic, Eoan and Focal
16:39 <blackboxsw> #topic Community Charter
16:40 <blackboxsw> As discussed at the last cloud-init summit we targeted a couple of streams of work that are easy to work in parallel, making them prime candidates for community involvement.
16:41 <blackboxsw> Those streams/themes are: updating and correcting datasource documentation at https://cloudinit.readthedocs.io/en/latest/topics/datasources.html
16:41 <blackboxsw> and    adding jsonschema definitions to any cloudinit.config.cc_* modules
16:41 <blackboxsw> any of these bugs are categorized as 'bitesize' and can be searched at the following link
16:42 <blackboxsw> #link https://bugs.launchpad.net/cloud-init/?field.tag=bitezise
16:43 <blackboxsw> a few of us have grabbed schema definitions for a few of the cloud config modules. I think we are up to 11 modules covered (of 50). Thanks all for the progress there. We have it on our roadmap to flesh out as much as we can
16:44 <blackboxsw> #topic Office Hours (next ~30 mins)
16:45 <blackboxsw> During this part of the meeting upstream devs should have eyes on the channel for any discussion related to feature, bug or review requests.
16:45 <blackboxsw> In the absence of active discussions, the active review queue will be be groomed.
16:46 <blackboxsw> for me, I've got to read through  https://github.com/canonical/cloud-init/pull/367  in depth to see if I have any use-cases  to add there for feature management
17:21 <blackboxsw> so, yeah sorry for the noise Odd_Bloke and falcojr in standup about whether this 'feature' is runtime configurable on/off. It doesn't even make sense for this  #include  case. Also I think the merits of falcojr's suggestion to rely on some unique environment variable to determine whether a feature is on or off can and should be encoded in cloud-init proper, instead of relying on patching when releasing to
17:21 <blackboxsw> ubuntu/xenial.
17:22 <blackboxsw> when we add a new 'feature' to cloud-init upstream. I believe we know what our expectations are for older stable releases at that time. We generally could encode those expectations (at least for ubuntu series which we maintain) that a feature should behave a certain way when we end up releasing to ubuntu/xenial.  Avoiding the RELEASE_BLOCKER comment as a reminder for us to manually patch a release wouldn't be
17:22 <blackboxsw> necessary in these cases.
17:26 <AnhVoMSFT> q question: when I specify a custom data to format/partition the datadisk, it seems like the ephemeral resource disk isn't getting formatted to ext4 anymore. Is this by-design that when the customer specifies disk_setup and fs_setup for additional datadisk they need to also include the fs_setup for ephemeral0 (it seems odd because disk_setup got "merged" properly. I could see the ephemeral0
17:26 <AnhVoMSFT> got partitioned. Yet fs_setup isn't).
17:27 <AnhVoMSFT> I am not sure if this is an appropriate topic for Office Hours. I can wait :-)
17:30 <blackboxsw> AnhVoMSFT: thx for the question. so, what version of cloud-init and what's the user-data for partitioning that is isn't working as expected?
17:31 <AnhVoMSFT> https://pastebin.com/TG4E8Dft 19.4-33 (latest 18.04 image on Azure)
17:33 <AnhVoMSFT> (paste.ubuntu has been giving me problems today - not sure if it's only me)
17:49 <meena> blackboxsw: no mention of my work on the net refactoring or did i miss that
17:53 <blackboxsw> meena: sorry, right that is a large undertaking that you've raised via your PR https://github.com/canonical/cloud-init/pull/363
17:55 <meena> yeah, it's my: please teach my software engineering while all i do is code monkeying PR.
17:55 <meena> don't tell no one tho, or else they… might not.
17:58 <Odd_Bloke> blackboxsw: Could you comment on the PR where we're having that feature flag conversation, please?
17:58 <blackboxsw> Heh, generally the direction meena is going is toward distro-specific networking subclass to handle network rendering details (as most of our network rendering utility functions are highly distro-dependent
17:59 <blackboxsw> Odd_Bloke: yes, I shall.
17:59 <Odd_Bloke> Thanks!
18:06 <blackboxsw> Ok, I forgot to close out the meeting.
18:07 <blackboxsw> AnhVoMSFT: so I see your instance is properly "waiting" for the presence of ephemeral0  resource disk. trying to get to the bottom of why formatting isn't being addressed there.
18:10 <blackboxsw> I see 2020-05-19 17:20:24,072 - cc_mounts.py[DEBUG]: Mapped metadata name ephemeral0 to /dev/disk/cloud/azure_resource
18:10 <blackboxsw> 2020-05-19 17:20:24,073 - cc_mounts.py[DEBUG]: changed default device ephemeral0 => /dev/disk/cloud/azure_resource-part1
18:16 <AnhVoMSFT> @blackboxsw this is reproducing 100% of the time
18:17 <blackboxsw> I'm wondering AnhVoMSFT if the ephemeral0 alias needs to be used instead. something like https://paste.ubuntu.com/p/7wmMc8drZ3/
18:19 <blackboxsw> I see we've done SRU testing referencing that alias instead of full resource disk path https://github.com/cloud-init/ubuntu-sru/blob/master/bugs/b59870ca.txt
18:23 <AnhVoMSFT> @blackboxsw, my config is actually having an EXTRA datadisk
18:23 <AnhVoMSFT> so in this case the VM is deployed with an additional data disk attached to the VM
18:24 <blackboxsw> #endmeeting