| 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 | 00:17 |
|---|---|---|
| meena | does service have an "enable" on alpine? | 08:48 |
| meena | minimal is gone | 08:48 |
| 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 | 09:10 |
| 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:11 |
| meena | oliver1234: that sounds like an ordering issue, too… | 13:18 |
| meena | like, we should wait until the dhcp request has returned | 13:18 |
| 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:19 |
| meena | nope, doesn't | 13:21 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| meena | falcojr: which timezone is everyone in, btw? | 13:37 |
| 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:40 |
| falcojr | (trying not to ping everybody) | 13:41 |
| aciba | I am UTC+2 | 13:42 |
| falcojr | thanks aciba, not sure how much you had interacted yet | 13:42 |
| meena | i've read aciba's commits… that's about it :D | 13:43 |
| 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:50 |
| falcojr | oliver1234: looks good, thanks! | 13:51 |
| meena | i just made a request for test data: https://cathode.church/@meena/109025428322535499 | 14:09 |
| meena | i forgot how intuitive Python is… it's not ["elements", "in", "list"].join(","), it's ",".join(["elements", "in", "list"]), of course | 14:34 |
| 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:39 |
| 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:46 |
| 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:55 |
| 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) | 14:57 |
| SDes91 | aciba so in essence installing cloud-init via APT will install the systemd unit files for me during the preparation phase. | 15:01 |
| 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:02 |
| aciba | SDes91: right, installing it via apt will configure the systemd services | 15:03 |
| 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:06 |
| SDes91 | via an HTTP Server which can then be used to configure the image on first boot. | 15:07 |
| === cpaelzer_ is now known as cpaelzer | ||
| aciba | SDes91: cool! let us know how it goes :) | 16:45 |
| minimal | and SDes91 is gone.....was going to make some comments but not sure he checks the channel logs | 16:57 |
| 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 | 17:10 |
| === EugenMayer6 is now known as EugenMayer | ||
| === EugenMayer4 is now known as EugenMayer | ||
| 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 | 18:17 |
| === EugenMayer5 is now known as EugenMayer | ||
| 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:48 |
| blackboxsw | thx meena for lighting the fire here. | 19:50 |
| 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:51 |
| 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:54 |
| blackboxsw | right now I distros.__init__ only defines 'freebsd' in OSFAMILIES | 19:55 |
| meena | huh? | 19:55 |
| 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:57 |
| 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 | 19:58 |
| 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:00 |
| 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:02 |
| 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:03 |
| 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:04 |
| meena | https://github.com/canonical/cloud-init/blob/main/cloudinit/netinfo.py | 20:05 |
| meena | i wish I could even remotely tell what the difference is between NetBSD ifconfig and … the other ifconfig is. | 20:08 |
| falcojr | blackboxsw: I stole and was testing your LXD test changes, but ran into an unrelated (I think) failure | 20:16 |
| 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:17 |
| falcojr | or is there something we can/should be doing to wait for the socket to be present? | 20:18 |
| 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:28 |
| blackboxsw | also I have pushed that branch https://github.com/blackboxsw/cloud-init/tree/test-lxd-datasource-md | 20:29 |
| blackboxsw | which had whatever WIP PR I had from friday. | 20:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| blackboxsw | aciba ^^ (for tomorrow) | 20:38 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| blackboxsw | excessive is a good word for it | 20:54 |
| 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:00 |
| 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 | 21:01 |
| blackboxsw | falcojr: I started a conversation on this over in #lxc channel we'll see if we get a response | 22:02 |
| 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 :/ | 22:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!