| meena | someone upgraded curl again, so building any python package means I'll have to build rust | 00:06 |
|---|---|---|
| meena | twice, if I wanna test amd64 and aarch64. | 00:06 |
| minimal | meena: Scaleway seem to have gotten rid of their Arm machines in 2020: https://www.theregister.com/2020/04/21/scaleway_arm64_cloud_end_of_life/ | 00:13 |
| minimal | but then reintroduced AI-specific Arm machines last December | 00:13 |
| minimal | meena: the Risc box is bare metal so I guess that would depend on whether FreeBSD has drivers for its networking/storage etc | 00:22 |
| meena | aye | 00:27 |
| * holman is excited for freebsd LXD support | 04:30 | |
| blackboxsw | Burnin' the midnight oil. cloud-init 24.1 is released! Folks have been relentless in pursuit of quality this release. Thank you all for your contributions meena(BSD) && minimal(Alpine) and holman for driving this release work effort this round. | 04:31 |
| blackboxsw | we just pushed the release to Ubuntu Noble `[ubuntu/noble-proposed] cloud-init 24.1-0ubuntu1 (Accepted)` https://github.com/canonical/cloud-init/releases/tag/24.1 | 04:32 |
| === blackboxsw changed the topic of #cloud-init to: 24.1 Released 02/29 | File bug: https://github.com/canonical/cloud-init/issues/new/choose | PRs: https://git.io/JeVed | release schedule: https://discourse.ubuntu.com/t/2024-cloud-init-release-schedule/41679 | ||
| === kuraudo1 is now known as kuraudo | ||
| dbungert | hi folks. Are you tracking an issue in non-EC2 environments with the error "cloudinit.sources.DataSourceEc2:583 Calling 'None' failed"? haven't found one yet in the bug tracker, I'm looking at setting up a reproducer. | 15:26 |
| catred | I don't think anyone's reported a similar bug | 16:37 |
| dbungert | thanks. I have a local reproducer here, will file. | 16:37 |
| catred | Thank you! | 16:41 |
| dbungert | ooo, nice "please file a bug at" prompt | 17:26 |
| dbungert | cloud-init added to LP: #2055077, I will fix the Ubuntu-specific angle but because this involves some stock configuration I suspect it applies more broadly. | 17:43 |
| -ubottu:#cloud-init- Launchpad bug 2055077 in livecd-rootfs (Ubuntu) "cloudinit.sources.DataSourceEc2:583 Calling 'None' failed" [Undecided, New] https://launchpad.net/bugs/2055077 | 17:43 | |
| falcojr | dbungert: does subiquity use nocloud-net? If so, it might be https://github.com/canonical/cloud-init/issues/4945 which we just SRUed the fix for yesterday | 17:53 |
| -ubottu:#cloud-init- Issue 4945 in canonical/cloud-init "nocloud-net not working in cloud-init >=23.4" [Closed] | 17:53 | |
| dbungert | falcojr: thanks. Good question. Reading that PR I lean toward this being a different issue, as I can see a None dereference in the EC2 code in the issue I'm discussing, but I'm not certain I would rule out entirely this nocloud-net part. | 17:56 |
| falcojr | dbungert: if early boot detection (ds-identify) doesn't discover a datasource, our python code will walk through all possible datasources to see if it can obtain metadata from them. NoCloud is one of the first ones it tries, and ec2 is one of the last ones. If NoCloud would've worked before but no longer did because of this bug, I would expect to | 17:58 |
| falcojr | see something like this | 17:58 |
| dbungert | Got it. I'll run through my typical no-cloud usage to see if it's affected. | 17:59 |
| falcojr | not saying there's not another problem on our end that we should also fix...just trying to figure out what changed there | 17:59 |
| falcojr | blackboxsw: ^, just because you're more knowledgeable about subiquity than me | 18:03 |
| blackboxsw | Yeah, I'll double check given our manual subiquity-live-installer script against noble. dbungert: this we think may affect live-desktop isos? | 18:09 |
| dbungert | blackboxsw: only some of them, I'm actively debugging to figure out the differences | 18:09 |
| blackboxsw | Thanks. I do find it very strange that ec2 is even being considered.... that points to ds-identify either being inactive/crashing or finding something that it considers is maybe ec2. I've also asked for cloud-init collect-logs on that bug so we can see how /run/cloud-init/ds-identify.log looks on that environment. But I'll get to setting the reproducer here too if I can. | 18:24 |
| dbungert | because the cloud.cfg is different in the good vs bad case I thought that would be it, but just swapping to the config from the good system isn't enough, so that's the angle I will be looking at this afternoon | 18:25 |
| falcojr | blackboxsw: if you look at the attached tar file, it looks like ds-identify didn't run. The cloud-init python code is checking the entire datasource list | 18:26 |
| falcojr | 2024-02-26 19:27:50,191 DEBUG cloudinit.sources:1038 Looking for data source in: ['NoCloud', 'ConfigDrive', 'OpenNebula', 'DigitalOcean', 'Azure', 'AltCloud', 'OVF', 'MAAS', 'GCE', 'OpenStack', 'CloudSigma', 'SmartOS', 'Bigstep', 'Scaleway', 'AliYun', 'Ec2 | 18:27 |
| falcojr | ', 'CloudStack', 'Hetzner', 'IBMCloud', 'Oracle', 'Exoscale', 'RbxCloud', 'UpCloud', 'VMware', 'Vultr', 'LXD', 'NWCS', 'Akamai', 'None'], via packages ['', 'cloudinit.sources'] that matches dependencies ['FILESYSTEM', 'NETWORK'] | 18:27 |
| falcojr | 2024-02-26 19:27:50,374 DEBUG cloudinit.sources:1004 Searching for network data source in: ['DataSourceNoCloudNet', 'DataSourceAltCloud', 'DataSourceOVFNet', 'DataSourceMAAS', 'DataSourceGCE', 'DataSourceOpenStack', 'DataSourceBigstep', 'DataSourceAliYun', | 18:27 |
| falcojr | 'DataSourceEc2', 'DataSourceCloudStack', 'DataSourceExoscale', 'DataSourceUpCloud', 'DataSourceVMware', 'DataSourceAkamai', 'DataSourceNone'] | 18:27 |
| falcojr | which...I'm not sure why, but it makes me think that our nocloud-net bug is what caused the change in behavior here because before it would've detected nocloud-net, but here it's not and then falling through to eventually trying ec2 | 18:29 |
| dbungert | falcojr: I'll explore that | 18:33 |
| blackboxsw | I must by blind, the attached installer.tar doesn't seem to contain cloud-init.log anywhere that indicates that behavior. | 18:43 |
| blackboxsw | also older noble live-desktop images were detecting nocloud due to /var/lib/cloud/seed/nocloud/(user-data|meta-data) files. I'm still trying to bring up the new image | 18:44 |
| falcojr | blackboxsw: sorry, it's in subiquity-server-debug.log.4937 | 18:45 |
| blackboxsw | man I was looking at 3246 | 18:46 |
| blackboxsw | thx | 18:46 |
| blackboxsw | falcojr: dbungert givent the "failed to load combined-cloud-config. file not found" I'm expecting that the snap refresh of the bootstrap was performed after a cloud-init clean or something on the host system. In that case no /run/cloud-init/ files would be present, thereby causing issues with stages.Init() trying to detect the datasource again | 20:22 |
| blackboxsw | sorry given the log file in that bug: `2024-02-26 19:27:50,112 DEBUG subiquity.cloudinit:24 Failed to load combined-cloud-config, file not found. This is expected for cloud-init <= v23.2.1.` | 20:22 |
| blackboxsw | dbungert: I just hit https://code.launchpad.net/~chad.smith/livecd-rootfs/+git/livecd-rootfs/+merge/461662 | 21:04 |
| blackboxsw | minor fix needed | 21:04 |
| dbungert | that looks reasonable | 21:04 |
| dbungert | on my side I'll also be opening a livecd-rootfs change, so we can batch that | 21:05 |
| blackboxsw | works for me | 21:05 |
| blackboxsw | for context of those in this channel, conversation migrated to ubuntu-devel channel, but here's the gist https://bugs.launchpad.net/ubuntu-desktop-provision/+bug/2055077/comments/6 | 21:59 |
| -ubottu:#cloud-init- Launchpad bug 2055077 in livecd-rootfs (Ubuntu) "cloudinit.sources.DataSourceEc2:583 Calling 'None' failed" [Undecided, In Progress] | 21:59 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!