== Meeting information == * #cloud-init: cloud-init status meeting, 02 Jun at 16:21 — 18:08 UTC * Full logs at [[http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-06-02-16.21.log.html]] == Meeting summary == ''LINK:'' https://cloud-init.github.io/ === Previous Actions === The discussion about "Previous Actions" started at 16:24. === Recent Changes === The discussion about "Recent Changes" started at 16:27. === In-progress Development === The discussion about "In-progress Development" started at 16:34. * ''LINK:'' https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018 === Community Charter === The discussion about "Community Charter" started at 16:47. * ''LINK:'' https://bugs.launchpad.net/cloud-init/?field.tag=bitezise === Office Hours (next ~30 mins) === The discussion about "Office Hours (next ~30 mins)" started at 16:50. == Vote results == == Done items == * (none) == People present (lines said) == * blackboxsw (76) * Odd_Bloke (6) * knaccc (5) * meena (5) * meetingology (4) * rharper (3) * ddstreet (1) * ubot5 (1) * smoser (0) == Full Log == 16:21 #startmeeting cloud-init status meeting 16:21 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 16:21 Available commands: action commands idea info link nick 16:21 hi folks, time for another cloud-init upstream status meeting. 16:22 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 this meeting is a welcome place for interruptions, questions, requests and unrelated discussions at any point. so don't be shy :) 16:23 #chair Odd_Bloke smoser rharper 16:23 Current chairs: Odd_Bloke blackboxsw rharper smoser 16:23 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 previous meeting minutes live here (and I just saw I forgot to publish last minutes so I pushed them now) 16:24 #link https://cloud-init.github.io/ 16:24 #topic Previous Actions 16:25 nothing actionable brought up in last meeting on 05/19 16:26 Odd_Bloke: ahh we should fix devel with those pkg drops on next upload 16:26 we did drop that for Xenial, Bionic Eoan and maybe focal too? 16:26 so an oversight for groovy 16:27 next topic 16:27 #topic Recent Changes 16:28 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 blackboxsw: When you say "next upload" are you referring to the upload you're about to do, or the one after that? 16:28 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 I think X, B E have all dropped them 16:29 so maybe I re-do ubuntu/devel PR Odd_Bloke ? 16:29 probably good/better/correct to keep all releases on the same footing. 16:29 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 yeah sounds good Odd_Bloke I'll re-do that devel PR (and make sure focal drops it too) 16:30 if needed 16:30 And it should just be a case of pushing a new commit to your existing branch. 16:30 Thanks! 16:30 +1 16:32 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 thanks Matthew 16:33 and chef_license support https://github.com/canonical/cloud-init/commit/0919bd46bbd1b12158c369569ec1298bb000dd8a 16:34 thanks bipinbachhao for the config extension there 16:34 #topic In-progress Development 16:35 a couple of new notables in flight at the moment: 16:38 - 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 and running, even amid not-critical failures 16:39 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 - 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 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 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 some of these changes will add the opportunity to enable 'new' features on platforms like Azure 16:43 and AWS 16:43 Azure (xenial) will be dropping walinuxagent support 16:44 AWS will now surface a datasource config option apply_full_imds_network_config boolean 16:45 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 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 the bug related to this SRU work is here 16:46 #link https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018 16:46 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 #topic Community Charter 16:48 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 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 bugs are filed for each config module which needs schema definition: 16:49 #link https://bugs.launchpad.net/cloud-init/?field.tag=bitezise 16:50 a big thanks to lucasmoura for starting to grab a number of these 16:50 #topic Office Hours (next ~30 mins) 16:50 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 In the absence of discussions/topics here we scrub the review queue. 16:51 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 and, let's update the topic for next IRC meeting too while we are at it 16:59 Odd_Bloke: just pushed ubuntu/devel dropping python3-six|unittest2|nose 17:01 and just re-pushed ubuntu/focal to drop python3-six 17:04 oops and missed you others. reworking 17:12 ok re-pushed. focal and devel PRs in shape 17:13 dropped the following build-deps: python3-six, python3-unittest2, python3-pep8, python3-nose, python3-pyflakes 17:20 blackboxsw: +1 on the ubuntu/devel upload. 17:21 whew, think we got all of the dropped deps between the two of us... thanks! 17:21 Odd_Bloke: thanks focal looks good and sbuilds 17:21 just finished eoan and building now to test 17:23 what? me?? 17:24 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 community notice: upload to Ubuntu groovy of cloud-init master accepted [ubuntu/groovy-proposed] cloud-init 20.2-45-g5f7825e2-0ubuntu1 (Accepted) 17:30 blackboxsw: One issue with https://github.com/canonical/cloud-init/pull/412 17:31 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 blackboxsw: yesterday, i tried to build an android app on my laptop and gave up after an hour. 17:35 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 Odd_Bloke: rharper so Xenial is interesting for datasource config via dpkg 17:55 We are missing: Hetzner, IBMCloud, Oracle, and RbxCloud 17:55 one was an oversight on previous SRUs 17:55 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 a little warning bell is going off in my head 17:56 Hetzner I thought was 'ok' 17:56 Oracle currently gets detected as OpenStack on Xenial. 17:57 IBMCloud and Oracle are sensitive 17:57 not sure about Hetzner or RbxCloud though 17:57 upstream Oracle datasource is 'good', but I wasn't sure if there was extra baggage associated with *not* backporting that functionality 17:57 blackboxsw: I think you might want to check with CPC on those 17:58 Hetzner is also detected as OpenStack on FreeBSD… but… only thru cloud-init itself, not thru ds-identify 18:03 (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 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 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 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 knaccc why do you want to change resolved 'Global' section? 18:08 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 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 level so that it appeared in the Global section, and then suddenly everything worked for the first time 18:08 I should tie off our cloud-init status meeting. Thanks folks for all who've attended 18:08 #endmeeting Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)