[16:16] smoser: no worries at all. [16:17] falcojr: ok going through SRU review on Azure PR at the moment. should wrap up in about 20 [16:18] I wanted to get to that Vultr PR too as I've let it languish since last week, but will address that after we sort SRU upload stuff [16:18] sounds good [17:47] falcojr: finally done https://github.com/canonical/cloud-init/pull/1006#pullrequestreview-746348616 approved [17:47] Pull 1006 in canonical/cloud-init "Set Azure to only update metadata on BOOT_NEW_INSTANCE (SC-386)" [Open] [17:48] blackboxsw: thanks, I'll work on the cherry picks [17:50] question about the dhclient-hook - wondering why there's this hook (and related code) for only dhclient and not for udhcpc or dhcpcd or another other DHCP client [17:50] is it something specific to dhclient or just that no-one has yet submitted similar support for other DHCP clients? [18:01] I'm honestly not sure about that. My guess is that it's that latter, but somebody with more project history might know [18:03] yeah I'm using dhcpcd (and occasionally udhcpc) here. Seems like there's at least 5 DataSouces that make use of/expect dhclient [18:06] I'll keep digging... [18:21] blackboxsw: https://github.com/canonical/cloud-init/pull/1008 [18:21] Pull 1008 in canonical/cloud-init "Ubuntu/bionic" [Open] [18:21] will have to refresh my context on dhclient hook and where it's used. I know it came about originally for Azure needs the hook itself gets called by /etc/NetworkManager/dispatcher.d/hook-network-manager [18:22] minimal: which is here https://github.com/canonical/cloud-init/blob/main/tools/hook-network-manager [18:23] from the looks of the implementation in the callsite it's limited to Azure [18:23] probably something to do with waagent setup/config etc. But would have to dig more [18:23] I also noticed the Ec2 datasource using dhclient for the ephemeral DHCP to talk to metadata server [18:24] falcojr: review on https://github.com/canonical/pycloudlib/pull/161 [18:24] Pull 161 in canonical/pycloudlib "Sru issues (SC-373)" [Open] [18:26] minimal: the sandboxed DHCP agent call in init-local timeframe on a number of datasources is used to potentially get access to a local metadata service if they were to offer link-local addressing on eth0 via the context manager EphemeralDHCPv4. So "networked" metadata services can be detected earlier during boot and provision the machine before general network has been setup by the OS. [18:26] blackboxsw: actually function maybe_perform_dhcp_discovery in dhcp.py checks only for dhclient binary. [18:27] looks like I've got a lot of code to read through to figure out what's needed for equivalent dhcpcd/udhpc support [18:28] right and that tension of only supporting dhclient has been brought up w/ SUSE too as why we don't look at using wicked I think. There has also been a hope that cloud-init would instrument it's own python-based dhclient that'd just do the right thing in the long-term using existing net modules. I can dig discussion/context that up later today as well. [18:30] thanks. I'm looking at this currently as related to the network hotplug stuff. In Amazon Linux on EC2 their stuff, via ec2-net package, at DHCP lease renew apparently also uses this to trigger setting up any secondary IPs on an existing interface, so trying to work out how to get this working with dhcpcd [18:35] yeah I think we were looking at instrumenting something simple using scapy modules for more generic os-agnostic dhcp handling [18:36] scapy would pull in a million dependencies, wouldn't it? [18:37] original context was we were concerned about pulling in the dependency, but I think that concern has been mitigated over time with the inclusion of this package in distro proper. One other concern with a dependency on scapy is how much it **could** affect boot times adding more early boot python module imports. My recollection was that it wasn't "that" bad/impactful. But, it'd need investigation [18:38] falcojr: right the dependencies was the main sticking point in those previous discussions [18:41] falcojr: i see your ubuntu/bionic branch. reviewing now [18:41] yeah deps would be a potential concern for me as I'm always looking for ways to reduce the deps [18:43] though having said that the Alpine scapy package is only 11mb with no deps beyond the usual Busybox and Python3 [18:45] falcojr: do we have a bug for the BOOT_NEW_INSTANCE thing? [18:46] falcojr: if not we should create one as that's going to be needed to replace the proposed upload [18:46] Right, we don't yet [18:49] falcojr: actually, since we haven't released yet. that bug is irrelevant [18:49] sorry for churn there [18:49] was just re-reviewing https://wiki.ubuntu.com/StableReleaseUpdates#Testing_for_Regressions [18:50] git diff [19:08] falcojr: +1 on your upload PR ubuntu/bionic [19:08] want to gen the others? [19:09] blackboxsw: focal: https://github.com/canonical/cloud-init/pull/1009 [19:09] Pull 1009 in canonical/cloud-init "Ubuntu/focal" [Open] [19:09] just dput bionic to ppa:cloud-init-dev/proposed [19:10] hirsute up [19:10] same process for impish? [19:11] falcojr:let's do new-upstream-snapshot for impish [19:11] and we'll hold that in the wings until SRU -proposed approval. [19:11] +1 [19:14] ehhh...actually thinking more about that, impish will release before 21.4...do we want Impish having a different version of cloud-init than what we've SRUed to the other releases? [19:17] focal approved https://github.com/canonical/cloud-init/pull/1009#pullrequestreview-746408827 [19:17] Pull 1009 in canonical/cloud-init "Ubuntu/focal" [Open] [19:20] falcojr: I'm okay with only cherry-picking the two commits to impish. it's the same amount of work in theory after impish is published/stable( new-upstream-snapshot will take care of dropping cpicks) [19:21] it'll also make the SRU reviewer have more context that impish is in fact the same as the cpicks into bionic/focal/hirsute [19:23] falcojr: but for impish, this instance-boot fix (and probably the retries will need bugs I think (because they are already released) [19:23] and we need to document those bugs for verification due to impish being in featurefreeze [19:25] the two are just bug fixes [19:25] https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_bugfix-only_updates [19:28] yes we can document in the changelog note in focal we had 20.1-9-g1f860e5a-0ubuntu1 "bug-fix-only during feature freeze" but each item carried a bug link [19:29] let's check in #ubuntu-release [19:34] ok falcojr you're right. [19:34] no bugs needed yet [19:35] wahoo! less paperwork! ;) [19:35] good to know on a friday [19:39] blackboxsw: hirsute is at https://github.com/canonical/cloud-init/pull/1010 , and impish https://github.com/canonical/cloud-init/pull/1011 [19:39] Pull 1010 in canonical/cloud-init "Ubuntu/hirsute" [Open] [19:39] Pull 1011 in canonical/cloud-init "Ubuntu/devel" [Open] [19:48] hirsute +1 [19:59] falcojr: approved impish [19:59] ok queuing uploads now [20:09] ok uploads look up I think and pushed to ppa:cloud-init-dev/proposed [21:03] AnhVoMSFT: looks like we are getting SRU upload approval now on hirsute, focal and bionic. I expect version 21.3-1-g6803368d-0ubuntu1~21.04.2 (note the .2 suffix) for testing on each release