16:21 <blackboxsw> #startmeeting cloud-init status meeting
16:21 <meetingology> Meeting started Tue Jun  2 16:21:15 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:21 <blackboxsw> hi folks, time for another cloud-init upstream status meeting.
16:22 <blackboxsw> we use this meeting to provide a venue for any cloud-init interested parties to keep up to date on current development, release-related info and expedite distributed development where possible.
16:22 <blackboxsw> this meeting is a welcome place for interruptions, questions, requests and unrelated discussions at any point. so don't be shy :)
16:23 <blackboxsw> #chair Odd_Bloke smoser rharper
16:23 <meetingology> Current chairs: Odd_Bloke blackboxsw rharper smoser
16:23 <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> previous meeting minutes live here (and I just saw I forgot to publish last minutes so I pushed them now)
16:24 <blackboxsw> #link https://cloud-init.github.io/
16:24 <blackboxsw> #topic Previous Actions
16:25 <blackboxsw> nothing actionable brought up in last meeting on 05/19
16:26 <blackboxsw> Odd_Bloke: ahh we should fix devel with those pkg drops on next upload
16:26 <blackboxsw> we did drop that for Xenial, Bionic Eoan and maybe focal too?
16:26 <blackboxsw> so an oversight for groovy
16:27 <blackboxsw> next topic
16:27 <blackboxsw> #topic Recent Changes
16:28 <blackboxsw> the following are commits landed in tip of master found via git log --since 05/19/2020 : https://paste.ubuntu.com/p/QFvgWhjXY9/
16:28 <Odd_Bloke> blackboxsw: When you say "next upload" are you referring to the upload you're about to do, or the one after that?
16:28 <blackboxsw> Odd_Bloke: if you'd like we can adjust the current upload so that devel, focal, bionic xenial eoan all drop those stale deps
16:28 <blackboxsw> I think X, B E have all dropped them
16:29 <blackboxsw> so maybe I re-do ubuntu/devel PR Odd_Bloke ?
16:29 <blackboxsw> probably good/better/correct to keep all releases on the same footing.
16:29 <Odd_Bloke> blackboxsw: I think it's worth doing, we've uploaded without fixing it a few times before, and we've remembered this time around.
16:30 <blackboxsw> yeah sounds good Odd_Bloke I'll re-do that devel PR (and make sure focal drops it too)
16:30 <blackboxsw> if needed
16:30 <Odd_Bloke> And it should just be a case of pushing a new commit to your existing branch.
16:30 <Odd_Bloke> Thanks!
16:30 <blackboxsw> +1
16:32 <blackboxsw> things of note in the recent commits landed.  https://github.com/canonical/cloud-init/pull/358  Mattew Ruffell  improved cc_grub_dpkg to be more dynamic in matching disks instead of a hardcoded device list
16:33 <blackboxsw> thanks Matthew
16:33 <blackboxsw> and chef_license support https://github.com/canonical/cloud-init/commit/0919bd46bbd1b12158c369569ec1298bb000dd8a
16:34 <blackboxsw> thanks bipinbachhao  for the config extension there
16:34 <blackboxsw> #topic  In-progress Development
16:35 <blackboxsw> a couple of new notables in flight at the moment:
16:38 <blackboxsw> - falcojr: introduction of feature-flags for cloud-init upstream to give us a toggle to retain original behavior of #include failures on stable downstream releases. https://github.com/canonical/cloud-init/pull/367  . Upstream cloud-init will fail loudly and raise an Exception if someone tries to #include a url which fails. this differs from original cloud-init behavior which was to try our best to get a system up
16:38 <blackboxsw> and running, even amid not-critical failures
16:39 <blackboxsw> per the above, if downstreams (distributiions) would like to retain a more permissive warn on #include user-data issues, a cloudinit/feature_overrides.py file would need to be introduced in the downstream
16:40 <blackboxsw> - Also meena and Odd_Bloke and others have been working toward a refactor of cloudinit.net modules. Dan added a doc PR to capture this approach https://github.com/canonical/cloud-init/pull/391
16:41 <blackboxsw> beyond that, there are a number of PRs up from lucas on json schema additions for cloudinit/config/cc_* modules to get better validation of #cloud-config user-data
16:42 <blackboxsw> For ubuntu proper, we have started the StableReleaseUpdate process for cloud-init to publish master into ubuntu/xenial, bionic, eoan and focal releases
16:43 <blackboxsw> some of these changes will add the opportunity to enable 'new' features on platforms like Azure
16:43 <blackboxsw> and AWS
16:43 <blackboxsw> Azure (xenial) will be dropping walinuxagent support
16:44 <blackboxsw> AWS will now surface a datasource config option apply_full_imds_network_config boolean
16:45 <blackboxsw> if set true in an Ec2(aws) image network configuration from cloud-init can come completely from IMDS for every connected NIC. That config will include all secondary IPv4/IPv6 addressses configured for the machine
16:46 <blackboxsw> Upstream has  started the Ubuntu SRU process (which generally takes around 10-14 days). We plan to include every commit that has landed in tip of master as of commitish 5f7825e22241423322dbe628de1b00289cf34114
16:46 <blackboxsw> the bug related to this SRU work is here
16:46 <blackboxsw> #link https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018
16:46 <ubot5> Ubuntu bug 1881018 in cloud-init (Ubuntu Focal) "sru cloud-init (19.4.33 to 20.2-30) Xenial, Bionic, Eoan and Focal" [Undecided,New]
16:47 <blackboxsw> #topic Community Charter
16:48 <blackboxsw> upstream has signed up to get as much of the json schema coverage as we  can for cloudinit/config/cc*py modules since invalid #cloud-config user-data formats tends to have one of the highest incidence of errors (because writing YAML is something humans shouldn't have to do :) )
16:49 <blackboxsw> so we are chopping away at defining JSON schema for as many cloud config modules as possible . there are still plenty to choose from. Anyone can feel free to grab a JSON schema bug and help us with bettering cloud-init
16:49 <blackboxsw> bugs are filed for each config module which needs schema definition:
16:49 <blackboxsw> #link  https://bugs.launchpad.net/cloud-init/?field.tag=bitezise
16:50 <blackboxsw> a big thanks to lucasmoura for starting to grab a number of these
16:50 <blackboxsw> #topic Office Hours (next ~30 mins)
16:50 <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.
16:51 <blackboxsw> In the absence of discussions/topics here we scrub the review queue.
16:51 <blackboxsw> since we are mid-stream on Ubuntu SRU at the moment, I'll be addressing review comments on some of the functional 'upload' branches we've put together
16:52 <blackboxsw> and, let's update the topic for next IRC meeting too while we are at it
16:59 <blackboxsw> Odd_Bloke: just pushed ubuntu/devel dropping python3-six|unittest2|nose
17:01 <blackboxsw> and just re-pushed ubuntu/focal to drop python3-six
17:04 <blackboxsw> oops and missed you others. reworking
17:12 <blackboxsw> ok re-pushed. focal and devel PRs in shape
17:13 <blackboxsw> dropped the following build-deps: python3-six, python3-unittest2, python3-pep8, python3-nose, python3-pyflakes
17:20 <Odd_Bloke> blackboxsw: +1 on the ubuntu/devel upload.
17:21 <blackboxsw> whew, think we got all of the dropped deps between the two of us... thanks!
17:21 <blackboxsw> Odd_Bloke: thanks focal looks good and sbuilds
17:21 <blackboxsw> just finished eoan and building now to test
17:23 <meena> what? me??
17:24 <blackboxsw> well yes indeedy meena, just trying to keep you highlighted as participating in the cloud-init status meeting :) you've thankfully reviewed, pushed and prodded us to talk about cloudinit.net refactor and how best to address it I think :) credit due ;)
17:26 <blackboxsw> community notice: upload to Ubuntu groovy of cloud-init master accepted [ubuntu/groovy-proposed] cloud-init 20.2-45-g5f7825e2-0ubuntu1 (Accepted)
17:30 <Odd_Bloke> blackboxsw: One issue with https://github.com/canonical/cloud-init/pull/412
17:31 <meena> blackboxsw: i'm just waiting for Odd_Bloke to provide the basic infrastructure so i can start moving code… without that, i have to bug other projects in my … 2 hours of free time per day.
17:31 <meena> blackboxsw: yesterday, i tried to build an android app on my laptop and gave up after an hour.
17:35 <blackboxsw> nice review again Odd_Bloke, will reflect that patch to each series. as every other ubuntu/* is missing enabling various cloud datasources beyond just Rbx
17:54 <blackboxsw> Odd_Bloke: rharper so Xenial is interesting for datasource config via dpkg
17:55 <blackboxsw> We are missing: Hetzner, IBMCloud, Oracle, and  RbxCloud
17:55 <blackboxsw> one was an oversight on previous SRUs
17:55 <blackboxsw> but Oracle and IBMCloud, I'm trying to recall if there is a reason we didn't want to surface either of those datasources as configurable on Xenial
17:56 <blackboxsw> a little warning bell is going off in my head
17:56 <blackboxsw> Hetzner I thought was 'ok'
17:56 <blackboxsw> Oracle currently gets detected as OpenStack on Xenial.
17:57 <rharper> IBMCloud and Oracle are sensitive
17:57 <rharper> not sure about Hetzner or RbxCloud though
17:57 <blackboxsw> upstream Oracle datasource is 'good', but I wasn't sure if there was extra baggage associated with *not* backporting that functionality
17:57 <rharper> blackboxsw: I think you might want to check with CPC on those
17:58 <meena> Hetzner is also detected as OpenStack on FreeBSD… but… only thru cloud-init itself, not thru ds-identify
18:03 <meena> (i'm not sure how much of that is my fault having helped a lot with Hetzner and FreeBSD and ds-identify myself)
18:03 <knaccc> Odd_Bloke thanks for your reply. I managed to fix things in the end, but kinda by cheating. Now my /etc/netplan/50-cloud-init.yaml only contains the IP addresses configuration, and I make the nameservers and search domain apply in the "Global" scope (as reported by systemd-resolve --status) by simply modifying the /etc/resolv.conf file. All configuration survives reboot just fine, and I am no longer
18:03 <knaccc> scared that resolv.conf will be overwritten because I found a web page that said that "Note: The mode of operation of systemd-resolved is detected automatically, depending on whether /etc/resolv.conf is a symlink to the local stub DNS resolver file or contains server names." Although you said in your message that "cloud-init will regenerate /etc/netplan/50-cloud-init.yaml on each boot, so yes, you don't
18:03 <knaccc> want to modify that", the OVH instructions directly contradict that and tell me to edit it to add all IP addresses to my interface (see Ubuntu 18.04 section here: https://docs.ovh.com/gb/en/vps/network-ipaliasing-vps/). I'm therefore very confused about why OVH seem to contradict the instructions that are in that config file, and confused as to what other location I should be editing/creating instead
18:06 <ddstreet> knaccc why do you want to change resolved 'Global' section?
18:08 <blackboxsw> heh meena not at fault :) . Just need to make sure we move cloud-platforms to a better way of detecting the right datasource when we can.
18:08 <knaccc> ddstreet if I put the nameservers and search domain into the /etc/netplan/50-cloud-init.yaml file, it gets ignored completely (i.e. although those configurations show up in systemd-resolve --status against that specific "link", the "Global" nameservers and lack of any search domain in that Global section are taking precedence). Therefore I had to configure nameservers and search domain at the resolv.conf
18:08 <knaccc> level so that it appeared in the Global section, and then suddenly everything worked for the first time
18:08 <blackboxsw> I should tie off our cloud-init status meeting. Thanks folks for all who've attended
18:08 <blackboxsw> #endmeeting