[12:29] <meena> aciba: thanks for the review
[12:36] <aciba> meena: it's a pleasure
[12:36]  * meena wonders why holman wants her to remove that # vi: line…
[14:11] <lioyerar> hello everyone, I have a question on module frequency once-per-instance, how cloud-init knows a module with that frequency is already launched? where the information is stored. Thanks
[14:38] <lioyerar> Ok, i find a usefull link
[14:38] <lioyerar> https://cloudinit.readthedocs.io/en/latest/topics/dir_layout.html
[14:39] <aciba> lioyerar: https://cloudinit.readthedocs.io/en/latest/topics/boot.html#first-boot-determination
[15:14] <meena> Goneri: heya! I'll be writing lots of code… and probably rewriting lots of your code ;)
[15:15] <Goneri> @meena go ahead, ping me if you want me to test your changes.
[15:15] <meena> Goneri: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266847 soon easier to test
[15:15] <meena> also, need to do that for NetBSD and OpenBSD, but, baby steps
[15:16] <meena> OpenBSD folks were upset that make test doesn't (even almost) pass
[15:16] <meena> and both, NetBSD and OpenBSD have their own cloudy thing, which does some very few basics…
[15:17] <Goneri> I've got my script that I use for bsd-cloud-image.org, they are all public, but yeah an up to date port is important.
[15:17] <Goneri> Cloudy thing?
[15:20] <meena> Goneri: http://ports.su/sysutils/cloud-agent for OpenBSD, and ec2_init for NetBSD: https://nxr.netbsd.org/xref/src/distrib/utils/embedded/files/ec2_init
[16:34] <shivaya> hi folks, is there a way to have cloud-init (user-data) create raid 1 root disk? i was going through the docs and was unable to find any info on that
[16:47] <meena> shivaya: unless you do it as a bootcmd, and it doesn't destroy the existing root disk
[16:58] <shivaya> meena: how do you mean? let's say I have 2 blank disks and I wanted to have cloud-init make them into mdraid and install the OS on it
[17:40] <meena> shivaya: that's not what cloud-init does. you usually put an image onto a machine, and cloud-init fits it properly
[17:58] <shivaya> meena: so cloud-init is not supposed to be used as a replacement to the old preseed automated install? 
[18:04] <holman> meena: no need, you don't have to remove that line
[18:05] <holman> meena: I don't see the value in having it in every file (we don't switch format per-file), and only some of the files have that line so for consistency I've been dropping it when I see it.
[18:06] <meena> holman: aye, I can drop it, no problem
[18:06] <meena> holman: it's not like we don't have an auto formatter
[18:06] <holman> meena: right
[18:07]  * meena goes to get laptop
[18:08] <holman> meena:  that's a pattern I've seen in other older codebases, but it seems a bit dated and I've never gotten a straight explanation on it (why not just mention [neo]vi[m] format expected in a dev doc)
[18:12] <meena> holman: dropped it, will follow that in the future with other files
[18:12] <holman> mmeena: sounds good :)
[18:13] <holman> shivaya: "old preseed automated install" sounds like you're talking about subiquity's autoinstall usage of cloud-init
[18:18] <shivaya> holman: yes, i was under the impression that cloud-init is THE new autoinstall method 
[18:18] <shivaya> now i am confused, can't figure out the difference :)
[18:18] <holman> shivaya: Subiquity is an OS installer (which happens to use cloud-init). 
[18:19] <holman> shivaya: cloud-init: inits cloud images
[18:20] <shivaya> pardon my ignorance, what is supposed to be used as autoinstall with subiquity? something like kickstart on RHEL or d-i on debian 
[18:20] <holman> shivaya: I don't follow the question
[18:21] <holman> subiquity is the autoinstaller
[18:22] <shivaya> ah not the ubiquty :). say i want to have pxe boot ubuntu iso and run automated install. looking around i figured cloud-init was the way to kick off the automated install like that. sounds like i was on the wrong path 
[18:22] <meena> yeah, no
[18:23] <meena> cloud-init is not a replacement for kick-start or d-i or similar
[18:24] <meena> once you're done installing stuff, you create a (golden) image, and go from there
[18:24] <holman> Ah, just noticed that the autoinstall docs describe their config as "cloud-init config", which is not actually a valid cloud-init config. That's unfortunate :/
[18:25] <meena> this might be less useful for hardware, unless you're provisioning loads of the same hardware
[18:25] <shivaya> i thought i read somewhere that ubuntu is dropping the support for preseed unattended install (d-i) in favor of cloud-init autoinstall 
[18:25] <shivaya> so what is the preferred way of doing the unattended install these days do you know? 
[18:26] <shivaya> tbh cloud-init works fine for me for what i need it except the mdraid on root disk 
[18:26] <shivaya> https://discourse.ubuntu.com/t/server-installer-plans-for-20-04-lts/13631 - this is what i ran across 
[18:30] <holman> shivaya: yeah, again unfortunate wording by docs of a different project (which causes confusion like this)
[18:31] <holman> looks like this maybe -> https://ubuntu.com/server/docs/install/autoinstall
[18:32] <holman> just realize that where it says "cloud-init config" it's talking about its own yaml-based config that isn't actually a valid cloud-init config
[18:32] <shivaya> thanks for clearing things up, i thought the yaml IS the cloud-init config 
[18:32] <holman> that's what is says, doesn't it :/
[18:32] <holman> it's not
[18:33] <shivaya> gotcha, sorry for the noise on the channel! 
[18:34] <holman> shivaya: No problem at all, you came to logical conclusions. Sorry I can't help more.
[18:34] <shivaya> you helped plenty, thanks again! 
[18:54] <meena> holman: what needs to happen for my two PRs to be merged?
[18:54] <holman> meena: me to look at them, sorry one sec
[18:56] <falcojr> holman: and for us to fix integration tests on main... :/
[18:56] <holman> err, that too
[18:57]  * meena wonders how hard it would be to fix make check to run on not-Linux
[18:57] <falcojr> holman: I'll get on that
[18:57] <holman> falcojr: thanks! let me know if/how I can help
[18:58] <holman> (happy to review)
[18:58] <meena> who broke then anyway?
[19:00] <falcojr> a change to cloud-images
[19:01] <meena> 🎶 who are the cookies from the cookie jar 🎶 
[19:01] <falcojr> it's an LXD related change that we use in our integration tests
[19:39]  * meena builds a VM to to … make check…
[19:44] <falcojr> blackboxsw: did we apply the diff here somewhere? https://github.com/canonical/cloud-init/pull/1734
[19:44] <falcojr> I could swear I did, but I'm not seeing the change on main
[19:44] <falcojr> the diff in the comment, not the actual PR changeset
[19:46] <blackboxsw> ahh no falcojr thanks for redirecting me to something useful.
[19:46] <blackboxsw> I had said I'd look over the failing integration tests, and my supplemental 'fix' was partway toward that end
[19:46] <falcojr> gotcha, I'm currently fixing CI, so was going to steal that
[19:47] <blackboxsw> ok thank you
[19:47] <blackboxsw> steal away.
[19:47] <blackboxsw> I was distracted by openstack multi-nic rendering questions
[19:47] <falcojr> "fix your cloud"
[19:48] <falcojr> but I have wondered if we should allow a way to override network config in userdata after the fact
[19:48] <blackboxsw> hah. historical reference point: James+1
[19:49] <blackboxsw> you mean a network_deferred key?
[19:50] <blackboxsw> it would be a cloud-platform generic way to do that if folks really want to override/augment network config beyond what the cloud IMDS or static seed files present to the instance.
[19:50] <blackboxsw> and folks wouldn't have to generate custom images and relaunch them, or provide runcmd hacks to regenerate and apply network config after the fact
[19:51] <falcojr> yeah, something like that
[19:52] <blackboxsw> but there's a lot of potential thrashing... and corner cases. potential of 1. other systemd units/services getting blocked or interrupted when they thing final network config is done, and 2. what does cloud-init do across reboot if network scope is rendered `Event.PER_BOOT` is set does it continue to reapply supplemental user-data config if IMDS base network config changes etc
[19:53] <blackboxsw> *when they think final network config is done*
[19:54] <blackboxsw> an interesting idea we could spike to see get broader feedback and see possible failure paths. Given the # of requests or attempts for setting network-config in user-data it might be a somewhat applicable use-case for folks who can't control the network metdata surfaced from IMDS and don't want to generate custom images
[19:55] <blackboxsw> since you are on CI failures, I'm reviewing PRs. 
[20:49] <falcojr> https://github.com/canonical/cloud-init/pull/1776 ready for review
[20:53] <blackboxsw> falcojr: running it through bionic/focal VM/container now
[20:53] <blackboxsw> almost complete on your doc Pr
[20:53] <blackboxsw> really nice work on that btw.
[21:02] <falcojr> oh whoops...sorry if you were still looking at the LXD one, I took your comment and Brett's +1 as good to go
[21:04] <meena> what makes cloud-init decide I need to fetch data from some URL, after reading an instance-id from a locally mounted meta-data?
[21:04] <blackboxsw> falcojr: all good, just letting the integration test run out on VM and container, I don't expect a problem, but wanted to see it before our daily jenkins runners see it
[21:06] <blackboxsw> meena: generally yes. if instance-id changes from what was cached down in /var/lib/cloud/data/previous-instance-id it'll determine that metadata configuration needs to be reapplied
[21:06] <meena> blackboxsw: but I did a cloud-init clean -slr, and I don't think cloud-init ran before
[21:08] <blackboxsw> meena: but each cloud platform may surface instance-id changes differently, and each cloud may also force a retry of get_data per boot because the datasource supports  EventType.BOOT, network config (Azure, Ec2, OpenStack, Rbxcloud):n
[21:10] <meena> blackboxsw: https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html so, how misleading is it to create meta-data here?
[21:10] <blackboxsw> meena: I didn't follow.
[21:12] <meena> blackboxsw: if cloud-init boots, and discovers no-cloud then reads meta-data, and decides to ignore the user-data and fetch it from somewhere else, isn't it… wrong to set meta-data?
[21:12] <blackboxsw> still don't follow the train of thought. If you create metadata in /var/lib/cloud/seed/nocloud(-net)?/meta-data and launch any instance on any cloud, NoCloud datasource will get detected even before the cloud-platform (because of /etc/cloud/cloud.cfg.d/*.cfg "datasource_list" key which defines priority order of datasource and metadata discovery.
[21:13] <meena> I should check the logs where this goes wrong then
[21:14] <blackboxsw> If cloud-init sees nocloud meta-data and user-data files in a seed directory (both are             "required": ["user-data", "meta-data"]) to detect nocloud datasource, then cloud-init should be bound to only use NoCloud datasource seed files for the life of cloud-init on that instance/config. It shouldn't also source other user-data sections or IMDS from other clouds.
[21:14] <blackboxsw> +1
[21:15] <meena> https://im.eena.me/uploads/553f0e1cba8d0628/cloud-init.tar.gz ← collect-logs
[21:16] <blackboxsw> yeah the comment "and fetch it from somewhere else" threw me for a loop as once a datasource is discovered, cloud-init doesn't try to merge any other datasource config sources. Just user-data/meta-data/network-config/vendor-data for NoCloud
[21:16] <meena> let's see.
[21:18] <blackboxsw> from cloud-init-output logs looks like no ds-identify available because cloud-init is trying all the datasources instead of a subset of viable datasources detected by /usr/lib/cloud-init/ds-identify, assume BSD (and it's you :) ).
[21:19] <blackboxsw> python code looks to be trying to detect the right priority order of datasources `2022-10-05 21:02:02,432 - __init__.py[DEBUG]: Looking for data source in: ['NoCloud', 'ConfigDrive', 'Azure', 'OpenStack', 'Ec2'],`
[21:21] <blackboxsw> meena: looks like that image doesn't actually have nocloud seed files in /var/lib/cloud/seed/nocloud/user-data/var/lib/cloud/seed/nocloud/user-data or /var/lib/cloud/seed/nocloud-net/user-data. So it says, Nope! " ` SUCCESS: no local data found from DataSourceNoCloud`
[21:22] <blackboxsw> note if cloud-init did find non-empty nocloud seed files in /var/lib/cloud/seed/* it would have logged the number of bytes read for those file reads
[21:22] <meena> blackboxsw: i have an cd9660 image attached
[21:22] <meena> it's not being mounted
[21:30] <blackboxsw> meena: is `util.find_devs_with("TYPE=iso9660")` returning anything for you?
[21:31] <meena> blackboxsw: i think i have a typo in my image name 😬
[21:33] <meena> i dunno how, but that typo might have also created a 20 GB image…
[21:35] <meena> can I alter the "default" user's shell?
[21:40] <blackboxsw> I think you may be able to provide this:
[21:40] <blackboxsw> #cloud-config
[21:40] <blackboxsw> system_info:
[21:40] <blackboxsw>   default_user:
[21:40] <blackboxsw>      name: bsduser
[21:40] <blackboxsw>      shell: <something_else>
[21:41]  * meena needs fish as shell, but fish needs installing…
[21:41] <blackboxsw> this is 'off the beaten path' otherwise you could modify the config in /etc/cloud/cloud.cfg on the image to set system_info: default_user: shell: there in the base/system config
[21:43] <meena> blackboxsw: everything i do is off the beaten path…
[21:44]  * meena grew on Solaris and FreeBSD… in a Linux world.
[21:45] <meena> running gmake check on FreeBSD 14.0-CURRENT now… 
[21:46] <meena> [21:46] <meena> first round
[21:47] <meena> now let's see how it fares with bash installed :D
[21:47] <holman> meena: I remember now that chkconfig on/off is how the sysv init systems I used to use enabled/disabled services
[21:47] <meena> holman: oh, right! I remember that too!
[21:48] <holman> I forgot that el6 actually did use sysv
[21:48] <meena> [21:48] <meena> that's not too bad.
[21:50] <holman> Nice :)
[22:00] <meena> now with pytest-cov and pytest-mock installed: [22:00] <meena> so, just 1 signed byte to fix.
[22:01] <meena> E           AttributeError: module 'socket' has no attribute 'AF_NETLINK'
[22:01] <holman> a _very_ linux attribute right there
[22:02] <meena> might be one of those cases where we just add @skip on not-Linux.
[22:03] <holman> that's used in Azure's _wait_for_all_nics_ready()
[22:04] <meena> aye
[22:04] <meena> i think that's enough for tonight tho
[22:05] <holman> seeya o/
[22:08] <meena> just to write this down, before i forget: to get tests running on FreeBSD, install: python3, gmake, py39-pytest, py39-responses, py39-pytest-mock, py39-pytest-cov, bash. (the py39- probably varies, and I need to find out how to do better)
[22:10] <meena> devel/py-pytest devel/py-pytest-cov devel/py-pytest-mock devel/py-responses
[22:10] <meena> o/~ good night now
[22:20] <blackboxsw> \o
[23:11] <meena> from bed: https://github.com/canonical/cloud-init/pull/1773    green!
[23:13] <meena> holman: alpine uses open-rc, which has a service wrapper, but the enable/disable work differently. i talked to minimal about this, and they have a different view on whether to provide such things to begin with