[00:32] <minimal> meena: nope, you'd have to boot off some other media and chroot into the OS to run grub-install
[04:25] <irshadh> Hi. I made a mistake on the Canonical CLA form here (https://ubuntu.com/legal/contributors/agreement). Is there a way to correct it? Thank you.
=== nikolay_ is now known as hjckr
[13:32] <meena> https://marc.info/?l=openbsd-ports&m=170488957300891&w=2 this is a lot of feedback
[14:07] <holmanb> irshadh: just sign it again with the correct information 
[14:11] <holmanb> meena: that is a lot
[14:11] <holmanb> meena: this one looks like it is based on false assumptions:
[14:12] <holmanb> > that way the user gets the templates somewhere in the system and they can choose when to use them.
[14:13] <holmanb> since these template files don't get selected by users but by code, right? 
[15:06] <holmanb> minimal: does alpine use isc-dhclient?
[15:06] <holmanb> I don't see it in the depends https://git.alpinelinux.org/aports/tree/community/cloud-init/APKBUILD
[15:08] <holmanb> I've never looked at an APKBUILD before, but they look pretty intuitive
[15:11] <holmanb> minimal: also, I'm guessing that py3-tox isn't needed in checkdepends, since the check function only contains `python3 -m pytest` and doesn't invoke pytest via tox
[15:12] <holmanb> happy to toss a PR for that if you want it, but not really sure where/how to do that
[16:17] <minimal> holmanb: Alpine *can* use dhclient, udhcpc is the default DHCP client as it comes wityh Busybox, for more info regarding DHCP client see the "Additional Alpine packages required by specific DataSources" section of https://git.alpinelinux.org/aports/tree/community/cloud-init/README.Alpine
[16:18] <holmanb> minimal: ahhh, that has the missing information I was looking for
[16:18] <minimal> I specifically did not add dhclient as a dependancy and Alpine packaging does not have "Suggests" or "Recommends" unlike Debian/Ubuntu
[16:18] <holmanb> that makes sense, thanks!
[16:19] <minimal> basically once c-i creates a ENI file it then runs "ifup" which handles finding an installed DHCP client to use (udhcpc, dhclient, dhcpcd)
[16:20] <holmanb> gotcha
[16:20] <minimal> the only "issue" is where c-i wants to run a DHCP client directly itself for ephemeral DHCP, which is why I added that note
[16:21] <holmanb> I would expect udhcpc to work in ephemeral on several clouds
[16:21] <holmanb> I think udhcpc needs to add classless static routes and support for unknown options to work on OpenStack and Azure, maybe some others too
[16:21] <minimal> holmanb: APKBUILD files AFAIK are "conceptually based on" Gentoo's PKGBUILD files
[16:22] <holmanb> PKGBUILD are arch no?
[16:22] <minimal> ok? perhaps you're right, I forget :-)
[16:22] <holmanb> but yeah looks similar to a PKGBUILD, and also not that different than Gentoo's ebuild either
[16:23] <minimal> re: udhcpc, well that README does refer to using dhclient with those DSes as a requirement/"safe" choice
[16:23] <holmanb> agreed - the readme is how I'd write it
[16:24] <holmanb> the contributor who added udhcpc support said they'd come back to finish it, but never did
[16:24] <meena> holmanb: yeah, but i think a lot of unix grey beards are still rubbed the wrong way by a thing called templates being in etc
[16:25] <minimal> as for py3-tox, ok I'll try a package rebuild without it to verify. I *think* someone else might have added that dep as originally the package didn't run any tests at all and someone else (2 years ago?) then enabled the tests
[16:25] <holmanb> I'll add an issue on GH for finishing udhcpc and ping them in case they feel like finishing it
[16:25] <minimal> meena: if you look at my Alpine packaging I actually remove all the non-Alpine and non-general templates
[16:26] <minimal> likewise I remove non-Alpine modules (i.e. Debian APT ones etc)
[16:27] <meena> why not allow people to transform alpine onto Debian using cloud-init 
[16:27] <minimal> I once tried removing all the non-ENI network ones but then had runtime errors and so left those in
[16:27] <holmanb> minimal: sounds good. Tox is just used during development and in Github Actions to manually install the python dependencies using pip and requirements.txt (and the other requirements files). On distros you probably want to test with the distro-provided dependencies, tox doesn't really make sense (and in your case isn't even used).
[16:27] <minimal> I'm not sure what "transform alpine onto Debian using cloud-init" means
[16:28] <minimal> you mean replace an installed and running Alpine system with a Debian one?
[16:28] <meena> cc_debianize.py
[16:29] <minimal> what is cc_debianize.py? That's not in the c-i source
[16:30] <meena> because I just made it up
[16:30] <minimal> so I'm still not sure what you're referring to
[16:31] <meena> but, like, have you never bootstrapped Debian from some other OS? or perhaps in your case bootstrapped Alpine from something else 
[16:31] <meena> anyway, I'm just rambling nonsense, sorry
[16:32] <minimal> I did ask whether you meant "you mean replace an installed and running Alpine system with a Debian one?"
[16:32] <minimal> in which case the Debian package of clout-init would be installed complete with its Debian templates
[16:33] <meena> I had to, on occasion, bootstrap FreeBSD (zfs) from FreeBSD (ufs)
[16:34] <minimal> I'm familiar with the general concept of "installing in place" as people sometimes/often do that for Alpine on VPSes where the provider does not have an option to create an Alpine VPS
[16:35] <minimal> but as I point out the cloud-init package for the "destination" distro/OS will have suitable c-i templates for it to use
[16:41] <meena> minimal: truth is: the reason for my rambling is: I'm deflecting, cuz I'm shying away from that kind of work for any of the BSDs
[16:45] <minimal> meena: https://git.alpinelinux.org/aports/tree/community/cloud-init/APKBUILD#n133 onwards is where I remove non-Alpine-relevant files during packaging
[17:32] <meena> minimal: that's kinda simple enough 
[18:01] <minimal> meena: now you've put the idea in my head of writing c-i user-data use with VPS/Cloud Providers who only have Debian/Ubuntu/whatever cloud-init images but no Alpine image to, on 1st boot, use a script ot replace the host OS with Alpine and then reboot, with the user-data then being used again (for the 1st time by Alpine) to do config :-)
[18:03] <minimal> I'll codename it either "Russian Doll" or "Trojan Horse" lol
[18:06] <meena> you're welcome
[20:01] <holmanb> cjp256: ping
[20:05] <holmanb> cjp256: I see that unknown-245 contains the same address as dhcp-server-identifier on azure. Is it ever the case that these two will contain different values?
[20:29] <holmanb> that code was ported from walinuxagent based on the commit history
[20:29] <holmanb> and in walinux agent i see a hint for why unknown-245 might be used
[20:30] <holmanb> a comment in a test introduced in commit c484d3012c0512c2 states "validate that the wireserver address is coming from option 245 (on default configurations the address is also available in the domain-name-servers option, but users may set up a custom dns server on their vnet)"
[21:11] <cjp256> holmanb: in theory they could be different.  I understand option 245 was meant to allow for changing the wireserver address, if needed.
[21:12] <cjp256> can you link to that commit? I don't see it in my repo
[21:22] <holmanb> cjp256: that commit was in walinux agent
[21:22] <holmanb> https://github.com/Azure/WALinuxAgent/commit/c484d3012c0512c2f6d9406d5c3a1b89d33eb323
[21:22] -ubottu:#cloud-init- Commit c484d30 in Azure/WALinuxAgent "Take wireserver address from option 245 in DHCP lease (#1303)"
[21:25] <holmanb> cjp256: gotcha, no worries I was just asking to be sure it is still needed
[22:19] <holmanb> meena: 
[22:19] <meena> holmanb: 
[22:19] <holmanb> I think the temp_utils.py also needs some help with ephemeral directory
[22:19] <falcojr> XD
[22:19] <meena> my
[22:20] <meena> I did think, that was too easy
[22:20] <holmanb> meena: probably not a real bug, but probably filling up directory with tempfiles over time
[22:20] <holmanb> could probably just replace _ROOT_TMPDIR with a call to helpers.Paths.run_dir
[22:23] <meena> who's idea was a module global constant anyway?
[22:23] <holmanb> I take that back, now that the bsd path is relocated this will cause bugs
[22:24] <holmanb> cmd/main.py and cmd/devel/logs.py each define their own /run/cloud-init variable
[22:24] <meena> https://github.com/canonical/cloud-init/commit/409918f9ba83e45e9bc5cc0b6c589e2fc8ae9b60
[22:24] -ubottu:#cloud-init- Commit 409918f in canonical/cloud-init "Use /run/cloud-init for tempfile operations."
[22:24] <meena> We should fix that before the next release
[22:25] <holmanb> meena: the problem isn't the module global constant, the problem is that it only gets used *sometimes*
[22:25] <meena> Also, the fact that it went unnoticed in tests tells me I've done a bad job testing that change
[22:26] <holmanb> also helpers/azure.py does it
[22:28] <meena> fun times
[22:29] <holmanb> there is also a user facing string in devel/render.py that is technically untrue since it _does_ use the right path but has hardcoded /run/cloud-init
[22:29] <holmanb> meena: I can file a bug if you want, lmk
[22:30] <holmanb> agreed, should fix it before next release
[22:31] <meena> please do, I'm in bed rn, and the only thing i need to get up for is to do some things I  forgot in the kitchen
[22:42] <holmanb> meena: sounds good, will do
[22:45] <holmanb> also just noticed a couple of calls to Paths({}), which is no-bueno