=== tdomingu is now known as TomD
[13:06] <ani> Is anyone working on https://github.com/canonical/cloud-init/issues/4598 ?
[13:06] -ubottu:#cloud-init- Issue 4598 in canonical/cloud-init "[enhancement]: Azure: Support for NVMe disks" [Open]
=== TomD is now known as TomDomin
[13:06] <ani> Is there any ETA on a resolution?
[13:06] <ani> This is about supporting NVME disks
[13:08] <ani> This is probably not even be a cloud-init bug but an azure platform issue
[14:49] <nikconwell> Hey all, is this the right place to chat about cloud-init DataSourceNoCloud?
[14:50] <falcojr> nikconwell: yes, this is the right place
[14:51] <holmanb> ani not that I know of, but it sounded like cjp256 was working on something related to this a while ago in the bug
[14:56] <nikconwell> Thx. Anyone having success with setting network configs (v2) via DataSourceNoCloud on Ubuntu 24.04? From debugging _get_data I can see my network-config is being read and parsed, but I can't for the life of me in the code see how that makes it anywhere since the data _network_config doesn't seem to be used in persist_instance_data. The data self.network_json does, but that doesn't seem to be set in DataSourceNoCloud.py _get_data()
[14:58] <nikconwell> (I can and am happy to file a bug, but I wanted to sanity check that I wasn't just doing something dumb and then filing a distraction bug)
[15:03] <falcojr> nikconwell: do you get an /etc/netplan/50-cloud-init.yaml ? There's a lot of extra code outside of the datasource used to configure networking
[15:08] <falcojr> the persist_instance_data is mostly about caching the info so we don't have to refetch things on future runs. I don't remember off the top of my head if/how network data is stored, but that shouldn't really affect network rendering
[15:20] <nikconwell> Thanks, maybe I was looking down the wrong path seeing that the stuff persisted was just the default...  There is the 50-cloud-init.yaml but I thought that was put in place by ubuntu and I'm supposed to override that with the network-config provided in my ISO for DataSourceNoCloud.
[15:25] <falcojr> Looks like we're missing a section heading, but if you look at the text above https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html#example-config , it explains how to include network-config alongside NoCloud user data. Cloud-init will take the network data and the write the os-specific network config. So for Ubuntu that
[15:25] <falcojr> means writing the netplan configuration at /etc/netplan/50-cloud-init.yaml, but on other OSes it could mean writing systemd-network configuration, Network Manager configuration or /etc/network/interfaces.d/
[15:29] <nikconwell> falcojr: Thanks, I have done that (created a version 2 network-data file), and I can see from the logs that it's being read (and converted to JSON without errors), but from tracking down the code it looks like that gets stored into _network_config (DataSourceNoCloud.py ln 208 near end of _get_data()) but then doesn't seem to go anywhere.
[15:30] <nikconwell> Or am I mis-interpreting and I actually have to write the 50-cloud-init.yaml file myself?
[15:32] <minimal> nikconwell: as falcojr mentioned cloud-init renders the NoCloud network-config into the appropriate distro-specific file, which for Ubuntu is 50-cloud-init.yaml
[15:32] <falcojr> if you have /etc/netplan/50-cloud-init.yaml, that means that cloud-init has read it and then converted it correctly. Ubuntu doesn't provide a default version of it
[15:33] <falcojr> you can see it gets used in `stages.py`, particular in `_find_networking_config()` which is called by `apply_network_config()`, but the code there is a bit convoluted.
[15:33] <nikconwell> Hmmm, then it's not getting overwritten by my network-config
[15:35] <minimal> overwritten? as falcojr mentioned that file does not exist in the 1st place - it is *created* by cloud-init (via a renderer) based on the network config
[15:35] <falcojr> if you provide a pastebin of your /var/log/cloud-init.log, that might help
[15:36] <falcojr> I'm guessing that it's using cloud-init's fallback config rather than seeing the config being passed
[15:36] <nikconwell> Sorry, meant overridden...
[15:37] <nikconwell> I'll pull the cloud-init.log. If it's not too confusing, I'm rerunning this after doing a cloud-init clean --logs during an install of ubuntu.  Doing cloud-init clean --logs and then cloud-init init --local
[15:38] <falcojr> oh...that could add a few layers of confusion XD
[15:39] <nikconwell> I can reboot and get a fresh cloud-init.log if that's better for understanding what's going off...
[15:40] <cjp256> ani: i've been packaging this up to populate links for nvme devices, landed in a few distros and currently working on debian  https://github.com/Azure/azure-nvme-utils/   -- whether we want cloud-init specific rules remains tbd but nothing prevents it
[15:41] <falcojr> nikconwell: cloud-init is already being used by the Ubuntu installer...both in the ephemeral enviornment (where the installation happens), as well as in the environment after installation, and the cloud-config lives in a different location depending on when you want it run. Are you just trying to debug something there? Why are you running commands
[15:41] <falcojr> manually?
[15:41] <nikconwell> Yes, was to try to debug to figure out why my network configuration wasn't being used. 
[15:42] <falcojr> are you wanting the network config applied to the ephemeral environment or after install reboot in the installed environment?
[15:44] <nikconwell> I was assuming it would be both the ephemeral and the install reboot. Your question is making me wonder if that was not a good assumption hahaah.
[15:47] <falcojr> I am less familiar with subiquity (the installer) so I may not be as helpful here, but https://canonical-subiquity.readthedocs-hosted.com/en/latest/explanation/cloudinit-autoinstall-interaction.html provides info about their interaction and the autoinstall documentation has separate network configuration.
[15:47] <falcojr> https://canonical-subiquity.readthedocs-hosted.com/en/latest/reference/autoinstall-reference.html
[15:52] <nikconwell> Paste of the lgos at https://pastebin.com/Mifq0YrA
[15:55] <nikconwell> 15:42:21,950-968 shows my network-data being loaded.
[15:58] <falcojr> but you're seeing something else at /etc/netplan/50-cloud-init.yaml? My only other guess is that subiquity docs say that its network configuration is applied during install and to the installed system, so it might be overwriting anything you're doing with cloud-init.
[15:58] <falcojr> https://canonical-subiquity.readthedocs-hosted.com/en/latest/reference/autoinstall-reference.html#network
[15:58] <falcojr> dbungert1: ^ does that sound right?
[15:59] <nikconwell> Correct, the /etc/netplan/50-cloud-init.yaml is just the default dhcp4 on en*
[16:02] <nikconwell> Ultimately my goal here is to just set the ip address (and authorized_key) via cloud-init and then can do all the other configs via Ansible later. My assumption here was that cloud-init would let me set that.
[16:03] <nikconwell> I looked over the autoinstall docs, I was hoping I wouldn't actually need to use that since I was thinking cloud-init could provide the network (via network-config) and key (via user-data) enough to get me going.
[16:08] <falcojr> well, based on the logs cloud-init appears to be doing the right thing. We can see it read the custom config and it says "writing to /etc/netplan/50-cloud-init.yaml", so it seems something else is overwriting it later.
[16:10] <nikconwell> Agreed, that's when I started going down the rabbit hole trying to debug to find out why my network-config wasn't seemingly working. Thanks for looking over the logs.
[16:10] <falcojr> would a cloud image work for your use cases? It doesn't include an installer and would just relying on cloud-init for initial configuration
[16:11] <nikconwell> Ultimately that's where I'm going, I was just thinking this was a quick/easy way to get into things. I'm on a VMware datacenter so I can build a cloud image template (which should have the cloud-init) and go with things that way, but I figured I could prototype with the installer since it's suppose to do cloud-init, etc.
[16:12] <nikconwell> Maybe I should just pivot to one of the cloud templates as you noted.
[19:09] <Odd_Bloke> So WRT https://github.com/canonical/cloud-init/issues/5392: would it be feasible to modify the schema not to warn on `system_info:` in the wrong place for 24.2?  (I'm assuming we can't figure out and implement the path off of system_info on that timescale, haha.)
[19:09] -ubottu:#cloud-init- Issue 5392 in canonical/cloud-init "[enhancement]: cloud-init does not provide a schema-compliant way to retain current `system_info` `package_mirrors` behaviour" [Open]
=== dbungert1 is now known as dbungert
[21:04] <falcojr> Odd_Bloke: we're thinking about patching existing releases but leaving it as-is for future releases. Any qualms with that?
[21:14] <Odd_Bloke> falcojr: So it'd be "fixed" as of next SRUs, and we have until oracular release to figure out how to properly resolve it?  That sounds ideal.
[21:15] <falcojr> cool, I'll get it into 24.2 then
[21:16] <Odd_Bloke> Thanks!
[21:28] <Odd_Bloke> Oh, and for avoidance of doubt, when you say "patching existing releases", can we expect the schema warning to remain gone for their lifetimes?  (That would potentially allow us to resolve the problem by serving up `apt:`-using vendor-data for oracular+.)