[00:31] <holmanb> minimal: nice :) thanks for sharing
[00:33] <holmanb> meena: is there anything special about freebsd on ec2 that would warrant this being datasource specific behavior? https://github.com/canonical/cloud-init/blob/040090a31f483014ec78cd353bb55bfae121bebd/cloudinit/sources/DataSourceEc2.py#L130  
[00:39] <meena> holmanb: what does a dhclient-script look like?
[00:40] <holmanb> meena: by default in cloud-init, it looks a lot like /bin/true ;)
[00:41] <holmanb> we use that as a hack to limit side-effects
[00:41] <meena> holmanb: then why does it need special-casing…?
[00:41] <holmanb> hrm?
[00:41] <holmanb> what do you mean by special-casing?
[00:41] <meena> or rather: What does it look like on EC2 that it needs special-casing?
[00:42] <holmanb> errr, I think you may be asking the same thing I am?
[00:42] <holmanb> I'm wondering why this behavior is specific to ec2
[00:43] <holmanb> the /bin/true reference: https://github.com/canonical/cloud-init/blob/main/cloudinit/net/dhcp.py#L150
[00:43] <minimal> cloudinit/net/dhcp.py also uses "-sf /bin/true"
[00:43] <minimal> snap :-)
[00:43] <holmanb> :)
[00:45] <minimal> holmanb: not directly related, but when I looked at the dhclient related stuff recently I was confused as to whether IPv6 is ever used (as then dhclient would need "-6" option)
[00:45] <meena> why use -sf then to begin with??
[00:45] <minimal> meena: i think he means to avoid any script being unexpectedly used
[00:46] <holmanb> yeah, avoiding using the default script is I think the end goal - there isn't a way to disable running the script, so it just uses /bin/true as a no-op
[00:46] <holmanb> minimal: I don't htink v6 is used yet
[00:46] <minimal> if you don't specify "-sf" at all then /sbin/dhclient-script is used if it exists
[00:47] <holmanb> and since avoiding calling /sbin/dhclient-script was the goal, which freebsd didn't support, I think that's why this freebsd-specific call ended up in the ec2 datasource
[00:47] <holmanb> looking at the commit history that's the story I'm seeing anyways
[00:47] <minimal> holmanb: ok, make sense. I was just starting to sketch out udhcpc and dhcpcd support and trying to understand current dhclient behavoiur as part of that
[00:48] <holmanb> minimal: +1 nice, udhcp and dhcpcd are the interesting ones on the ubuntu side as well
[00:49] <holmanb> however some sad news on the dhcpcd side
[00:49] <holmanb> the last post on the mailing list
[00:49] <minimal> let me check..........but I can guess what it is about
[00:50] <meena> either someone died, or they're ending development 
[00:50] <holmanb> somewhere in between, yeah
[00:50] <holmanb> https://roy.marples.name/archives/dhcpcd-discuss/0003457.html
[00:50] <holmanb> :/
[00:51] <meena> oh gosh
[00:51] <holmanb> updated on github as recently as 3 months ago by Roy
[00:51] <minimal> oh yeah, I read that at the time, I thought something had happened recently
[00:53] <holmanb> not that I know of
[00:54] <meena> holmanb: so, to summarize: https://github.com/canonical/cloud-init/blob/main/WIP-ONGOING-REFACTORIZATION.rst . DHCP needs to move into distro.
[00:56] <meena> seeing as the Azure people are going to rip out their special-casing (blacklist_driver[s]), I'm going to focus on moving get_interfaces/get_interface(s)_by_mac() into distro. All the ground-work is now there in BSD.
[00:56] <meena> And I can probably happily ignore some weird Linux weirdnesses, especially where they are completely undocumented.
[00:56] <holmanb> undocumented weirdness is where the fun is at
[00:57] <meena> holmanb: aaaaaaand that's why i like BSD… if something is undocumented, it's a bug, but even so, at least the code is easy to read and understand… and FIND.
[00:58] <holmanb> heh :D
[00:59] <minimal> well what I was going to point out is that both dhclient and udhcpc handle IPv4 and IPv6 via two different binaries/cli calls ("dhclient" and "dhclient -6", "udhcpc" and "udhcpc6") whereas dhcpcd does/can do both via a single call
[00:59] <holmanb> minimal: yeah, that's one of the reasons for the dhcpcd preference on our side as well
[01:00] <minimal> that was why I was tryingf to figure out if existing dhclient code used "-6" or not, and if so in which situation/order
[01:00] <minimal> as dropping dhcpcd in "out of the box" would try both v4 & v6 unless configured othewise
[01:01] <holmanb> minimal: I'll be queuing up some time for provisional dhcpcd support within the next month or two
[01:01] <holmanb> minimal: I was just comparing the man pages side by side and noticed that as well :-)
[01:01] <holmanb> never used cd myself
[01:01] <holmanb> dhcpcd
[01:02] <minimal> yeah I've not had much time to do clound-init stuff recently, only got rid of other stuff yesterday so want to get some backlogged c-i changes out as PRs in the next week or so
[01:02] <holmanb> we have datasource-specific dhclient calls scattered about as well, which complicate the task a bit
[01:04] <minimal> holmanb: my brief look into udhcpc/dhcpcd was also why I started wondering about network-config v2 DHCP settings as well (and then how they'd appear in eni so I could check they'd then get acted upon correctly in Alpine)
[01:05] <minimal> ^ IPv6 DHCP related settings I mean
[01:05] <minimal> well IPv6 SLAAC/DHCPv6/RA etc
[01:06] <holmanb> :)
[01:07] <minimal> but 1st to get those other code changes out the door....
[01:14] <meena> I'm fairly certain, btw, that FreeBSD's dhclient can't do DHCPv6 out of the box. You'd need to install something else… which could turn into a chicken egg problm
[01:14] <minimal> meena: no "-6" option for it?
[01:15] <meena> minimal: nope
[01:15] <minimal> it's ISC dhclient isn't it?
[01:16] <meena> https://github.com/freebsd/freebsd-src/tree/main/sbin/dhclient
[01:16] <meena> good grief… /*	$OpenBSD: dhclient.c,v 1.63 2005/02/06 17:10:13 krw Exp $	*/
[01:17] <holmanb> goodness
[01:17] <meena> like, it's been updated, or at least secured, and all, but… brrrr…
[01:17] <minimal> .\" Copyright (c) 1997 The Internet Software Consortium.
[01:17] <minimal> so its based on ISC's code, perhaps a prehistoric version
[01:18] <meena> #include <sys/capsicum.h> ← "secured"
[01:18] <holmanb> ah, yeah there's a comment about capsicum on the manpage as well
[01:18] <holmanb> falls back to a chroot for sandboxing
[01:18] <minimal> so I guess they forked it before ISC added IPv6 support
[01:19] <meena> they forked it before IPv6 was standardized, minimal.
[01:20] <minimal> meena: doesn't make my statement incorrect though ;-)
[01:20] <holmanb> LOL
[01:20] <meena> imagine sifting thru 25 years of ISC dhcplient code to try add IPv6 support today.
[01:21] <minimal> wonder if there's some more recent "useful" DHCPv4 options not supported then
[01:25] <meena> other than -sf? 🤷🏻‍♀️
[01:26] <meena> -1 seems useful…
[01:26] <minimal> well I'm guess it supports RFC3442
[01:26] <minimal> meena: yupe, the c-i code uses "-1" when it calls dhclient
[01:28] <minimal> it runs "/usr/sbin/dhclient -1 -v -lf /run/dhclient.lease -pf /run/dhclient.pid eth0 -sf /bin/true" on Linux
[01:29] <holmanb> I need to run
[01:29] <meena> i need to sleep
[01:29] <holmanb> seeya o/
[01:29] <minimal> cya
[15:58] <blackboxsw> aciba: ubuntu/devel branch merge to tip of main. I'm syncing it now, and will rekick integration test runners
[16:01] <aciba> blackboxsw: let's see the green color there :)
[16:27] <meena> minimal / holmanb: https://reviews.freebsd.org/D22012