[00:17] <minimal> meena: Alpine's openrc package provides "service" (as a softlink to rc-service so I never bothered to implement rc-service in distro/alpine.py
[08:48] <meena> does service have an "enable" on alpine? 
[08:48] <meena> minimal is gone
[09:10] <meena> I need to close those bugs, at least for FreeBSD… because service enable actually exists, and works
[09:10] <meena> which is not documented
[13:11] <oliver1234> hi! I'm trying to use the nocloud-net data source. But apparently cloud-init only tries to reach the "seed" HTTP server for ten seconds, while it may take about ten seconds until the network interface to get a DHCP address. Is that a known problem? Do you know a workaround for that? Currently this problem means that in many cases the automatic
[13:11] <oliver1234> installation fails.
[13:18] <meena> oliver1234: that sounds like an ordering issue, too…
[13:18] <meena> like, we should wait until the dhcp request has returned
[13:19] <oliver1234> yes, sounds good
[13:19] <meena> and, normally, I am pretty, and sure, we do
[13:19] <meena> makes me wonder if nocloud-net uses EphemeralDHCP class
[13:21] <meena> nope, doesn't
[13:26] <falcojr> yeah, that's definitely something that could be improved. oliver1234: do you mind creating a bug at https://bugs.launchpad.net/cloud-init ?
[13:27] <meena> like, it just makes the request, doesn't do any network setup at all
[13:27] <meena> it's pure chance when it works.
[13:28] <meena> falcojr: i opened up a couple of bugs yesternight, and then realized, some of them are badly formulated or researched.
[13:28] <oliver1234> falcojr: I'll try to open a bug report... What exactly is the bug you would propose to fix? That nocloud-net does not wait for DHCP to finish?
[13:28] <meena> The alpine bug can be closed, as minimal hinted at. the other half of that bug works, but only on FreeBSD, i added better comments today
[13:29] <meena> oliver1234: when in nocloud-net mode, cloud-init should do the same thing as other datasources that request data from the network.
[13:29] <falcojr> oliver1234: basically yeah, that NoCloud is attempting to read from the seed url without having any network setup
[13:37] <meena> falcojr: which timezone is everyone in, btw?
[13:40] <falcojr> depends on who "everyone" is, but for the ones you're used to talking to...me: US central, blackboxs_ and holma_: US Mountain (currently UTC-5 and -6 respectively). minima_: no idea
[13:41] <falcojr> (trying not to ping everybody)
[13:42] <aciba> I am UTC+2
[13:42] <falcojr> thanks aciba, not sure how much you had interacted yet
[13:43] <meena> i've read aciba's commits… that's about it :D
[13:50] <oliver1234> meena, falcojr: here's the bug report for the nocloud-net/DHCP race problem: https://bugs.launchpad.net/cloud-init/+bug/1990149
[13:50] <ubottu> Launchpad bug 1990149 in cloud-init "nocloud-net datasource attempts to read seed url before network is set up" [Undecided, New]
[13:51] <falcojr> oliver1234: looks good, thanks!
[14:09] <meena> i just made a request for test data: https://cathode.church/@meena/109025428322535499
[14:34] <meena> i forgot how intuitive Python is… it's not ["elements", "in", "list"].join(","), it's ",".join(["elements", "in", "list"]), of course
[14:39] <SDes91> Hi all, as side project I was just playing around with making a bootable disk image using Containers and I was able to create really minimalist OS images for Ubuntu, Debian (They really just have the kernel, initramfs and some dependencies in them). I wish to just experiment as the next step with cloud-init. what should be the steps for it?
[14:46] <blt> Hi there ! I have tried to merge same section from vendor-data and user-data from a Terraform file or even multiple user-data without any success, my latest file is erasing the first...I took a look on merge_how and the documentation but I am not able to have a working solution, am I missing an obvious detail ? vendor-data & user-data are working
[14:46] <blt> fine as long as they are not using the same section (packages, write_file...)
[14:55] <aciba> SDes91: What containarization technology do you use? If you have an init system you can add the different cloud init stages as dependencies of it, to see examples checkout: https://github.com/canonical/cloud-init/tree/main/systemd and https://github.com/canonical/cloud-init/tree/main/sysvinit. If not, you have to manually run those stages early on boot. More info under: https://cloudinit.readthedocs.io/en/latest/topics/boot.html
[14:57] <SDes91> aciba at the moment I Docker containers with Systemd. I was able to create bootable images using Hashicorp Packer + Docker that I was able to test via QEMU. (https://github.com/shantanoo-desai/PockerISO for reference)
[15:01] <SDes91> aciba so in essence installing cloud-init via APT will install the systemd unit files for me during the preparation phase.
[15:02] <aciba> SDes91: Then I guess the easiest way is to use a package manager to install cloud-init in the image. If a package manager is not an option, then you will have to manually install cloudini, including the systemd unit files
[15:03] <aciba> SDes91: right, installing it via apt will configure the systemd services
[15:06] <SDes91> appreciate it. if this works out I can let Packer serve the `user-data` and `meta-data` files upon image boot via QEMU.
[15:07] <SDes91> via an HTTP Server which can then be used to configure the image on first boot.
=== cpaelzer_ is now known as cpaelzer
[16:45] <aciba> SDes91: cool! let us know how it goes :)
[16:57] <minimal> and SDes91 is gone.....was going to make some comments but not sure he checks the channel logs
[17:10] <meena> minimal: i closed the alpine bug again, thanks for the help
[17:10] <meena> meena: also, FreeBSD has a *complete* service wrapper, NetBSD a partial one, and OpenBSD none at all
=== EugenMayer6 is now known as EugenMayer
=== EugenMayer4 is now known as EugenMayer
[18:17] <tobias1> I'm running into an issue where the metadata service URL is not what I think it should be with DataSourceMAAS... does anyone happen to know what it is *supposed* to be for MAAS (e.g., the local machine, rack controller, or something else)? https://discourse.maas.io/t/on-first-reboot-after-install-node-fails-to-bring-up-its-network-interface/6307/4
=== EugenMayer5 is now known as EugenMayer
[19:48] <meena> close as invalid: https://bugs.launchpad.net/cloud-init/+bug/1990072 only works incidentally.
[19:48] <ubottu> Launchpad bug 1990072 in cloud-init "mount helper: improve mount performance on BSDs" [Undecided, Invalid]
[19:50] <blackboxsw> thx meena for lighting the fire here.
[19:51] <meena> blackboxsw: so far, with some missteps, i know that it should be fairly easy to add support for FreeBSD to cc_syslogd, cc_ntp, and a few others
[19:51] <meena> OpenBSD and NetBSD need a bit more work.
[19:54] <blackboxsw> iterations will round it out. one is better than none. I wonder if it's worth differentiation  of "freebsd" from "openbsd", "netbsd" in terms for a module's cc_<module>.py supported 'distro' attribute.  I guess we'll see as the module changes take shape in PRs
[19:55] <blackboxsw> right now I distros.__init__ only defines 'freebsd' in OSFAMILIES
[19:55] <meena> huh?
[19:57] <meena> blackboxsw: that's 'freebsd': ['freebsd'], which can be extended to freebsd: ['freebsd', 'dragonfly']
[19:57] <blackboxsw> normally a `cc_*` config module defines what distros is supported on. in most cases it is 
[19:57] <blackboxsw> 'all' or some set of ubuntu, debian. SLES, or RedHat distros
[19:57] <meena> blackboxsw: but we can also go deeper: 'bsd': ['freebsd', 'netbsd', 'openbsd']
[19:58] <blackboxsw> right we can and maybe should go deeper if there are some config modules you think will not work on certain BSD flavors
[19:58] <blackboxsw> so that a module could say, I work with freebsd, but not netbsd
[20:00] <meena> like, i know how to make this work on FreeBSD, https://bugs.launchpad.net/cloud-init/+bug/1901915 bit I'd have to dig a lot deeper than my current knowledge to make it work on OpenBSD and NetBSD
[20:00] <ubottu> Launchpad bug 1901915 in cloud-init "FreeBSD: Add certctl support to cc_ca_certs" [Undecided, Triaged]
[20:02] <blackboxsw> If a cc_<module>.meta['distros'] definition is set and the current distro is not in 'distros' or 'all' then cloud-init automatically skips it and logs a message about that skip https://github.com/canonical/cloud-init/blob/main/cloudinit/config/modules.py#L302-L322-
[20:03] <blackboxsw> so if worthwhile/useful, we could make unique distinctions of different BSDs to allow FreeBSD to support something that NetBSD and OpenBSD don't yet support.
[20:04] <meena> aye
[20:04] <meena> I need to get a start on the ifconfig parser, and I'm hesitating, because, we already have one or two…
[20:05] <meena> https://github.com/canonical/cloud-init/blob/main/cloudinit/netinfo.py
[20:08] <meena> i wish I could even remotely tell what the difference is between NetBSD ifconfig and … the other ifconfig is.
[20:16] <falcojr> blackboxsw: I stole and was testing your LXD test changes, but ran into an unrelated (I think) failure
[20:17] <falcojr> in a focal VM, the instance was detected as NoCloud
[20:17] <falcojr> so failed the test
[20:17] <falcojr> which seems to be explained by this comment https://github.com/canonical/cloud-init/blob/main/tests/integration_tests/datasources/test_lxd_discovery.py#L32
[20:17] <falcojr> would this be an LXD bug then? Is there anything specific we should do about that?
[20:18] <falcojr> or is there something we can/should be doing to wait for the socket to be present?
[20:28] <blackboxsw> checking falcojr. it's possible that the race exists. Though I expected the socket file should be up quite a bit before we try to attach
[20:29] <blackboxsw> also I have pushed that branch https://github.com/blackboxsw/cloud-init/tree/test-lxd-datasource-md
[20:30] <blackboxsw> which had whatever WIP PR I had from friday.
[20:31] <falcojr> yeah, that's the one I was working with. You should get the credit if you wanna create the PR, otherwise I'm fine putting it up (I've made some small changes though)
[20:32] <blackboxsw> falcojr: I only pushed so you'd have a diff reference point as I think I made changes after my comment on your PR only for code errors I had in my review comment .
[20:32] <falcojr> CLOUD_INIT_PLATFORM=lxd_vm CLOUD_INIT_OS_IMAGE=bionic pytest tests/integration_tests/datasources/test_lxd_discovery.py is reproducing consistently for me
[20:33] <blackboxsw> falcojr: holman if we are trying to release a 22.3.3 package version into kinetic for these release bug fixes. then any subsequent `new-upstream-snapshot` will end up generating a deb pkg version which is < 22.3.3 because it will be something like `22.3-43` not the hyphen not a dot. I honestly don't know if we would really prefer to represent subrevisions in our `cloudinit/version.py` or not.
[20:34] <blackboxsw> https://github.com/canonical/cloud-init/pull/1741#discussion_r974655351 is the context
[20:34] <ubottu> Pull 1741 in canonical/cloud-init "22.3.3 Release Into Kinetic" [Open]
[20:35] <blackboxsw> generally we only bump cloudinit/version.py  after an official upstream release. But when we have hotfixes or bug fixes added to an official upstream release, it forces us to publish subrevisions such as `22.3.3` which I don't think we really want to represent in our development 'main' branch
[20:36] <blackboxsw> if we don't pull in that subrevision into cloudinit/verion.py we will have to manually (or with tooling) ensure new-upstream-snapshot knows to continue to generate `22.3.3-` based package prefixes for every release into bionic|focal|jammy|kinetic untill 22.4 comes out
[20:37] <blackboxsw> given that 22.4 is Nov 1st. it's not 'too long' to handle this https://github.com/canonical/cloud-init/pull/1741#discussion_r974655351
[20:37] <ubottu> Pull 1741 in canonical/cloud-init "22.3.3 Release Into Kinetic" [Open]
[20:37] <blackboxsw> given that 22.4 is Nov 1st. it's not 'too long' to handle this https://discourse.ubuntu.com/t/cloud-init-2022-release-schedule/25413
[20:38] <blackboxsw> aciba ^^ (for tomorrow)
[20:45] <blackboxsw> falcojr: I see the same symptom: `lxc launch ubuntu-daily:bionic lxd-b-vm --vm -p pycloudlib-vm-bionic-v3` resulting in nocloud, yet lxd socket is up
[20:45] <falcojr> "forces us to publish subrevisions such as `22.3.3` which I don't think we really want to represent in our development 'main' branch" Why? I'm not sure I see a problem with it
[20:46] <blackboxsw> only the problem that 22.3.3 is not truly represented cleanly in upstream/main. If we add the one commit to upstream/main:cloudinit/version.py now our python version represents a point in time today that is way past the 22.3.3 upstream release
[20:47] <blackboxsw> I guess it doesn't truly matter to represent that upstream/main is `22.3.3` based as it does include those specific commits already.
[20:47] <falcojr> ah, right
[20:48] <blackboxsw> but we'll start seeting 22.3.3-1 which sort of implies we are one commit past the annotated change.  But, maybe that's ok as it's our development branch
[20:48] <falcojr> yeah, I see why that's not great
[20:48] <blackboxsw> and the only things that really should matter are the upstream 22.4/23.1  releases etc, everything else is development.
[20:50] <blackboxsw> falcojr: 2022-09-19 20:42:08,753 - __init__.py[DEBUG]: Searching for local data source in: ['DataSourceNoCloud', 'DataSourceLXD'] in bionic
[20:50] <blackboxsw> that order is off
[20:50] <blackboxsw> wait jussec, that order is fine. sry
[20:50] <falcojr> blackboxsw: for now can we do a manual version change and update the process/tooling before the next release?
[20:51] <falcojr> blackboxsw: there is this in the test: https://github.com/canonical/cloud-init/blob/main/tests/integration_tests/datasources/test_lxd_discovery.py#L34
[20:51] <blackboxsw> falcojr: yes we can manually set the version on the kinetic upload to conform to major.minor-<commit_offset_count>
[20:51] <falcojr> (interleaving conversations are fun :P )
[20:51] <blackboxsw> heh
[20:52] <falcojr> I think lets do that for now
[20:52] <falcojr> long term is it possible to change how we specify our ubuntu version number, or is that set in stone?
[20:53] <falcojr> <major>.<minor>-<commit_since_release>-g<commit>-<whoknowswhat>ubuntu<ubuntu_revision>-<series>.<series_revision> has always felt a bit...excessive?
[20:53] <blackboxsw> yes definitely package versioning is something that can change. We just need to make sure we account for this newer upstream release subrevision or generally switch to 
[20:53] <blackboxsw>  semantic versioning instead of <year>.<release_count> versioining
[20:54] <blackboxsw> excessive is a good word for it
[21:00] <blackboxsw> ahh falcojr ok LXD problem on bionic. bionic doesn't auto-start lxd agent, but pycloudlib profiles provide `user.vendor-data` to lxd config and the launched instance via a cloud-init:config drive /dev/sr0 that the instance can see as nocloud datasource
[21:01] <blackboxsw> now that LXD ships lxd socket API on bionic and prefers that medium, I think our pyclodulib profile needs to change to just set cloud-init.vendor-data config on the bionic instance launches. testing this theory now
[22:02] <blackboxsw> falcojr: I started a conversation on this over in #lxc channel we'll see if we get a response
[22:03] <blackboxsw> bionic vms have a chicken/egg problem given that lxd-agent doesn't run, we may be bound to our CI detecting NoCloud datasource on VMs :/