| === paride7 is now known as paride | ||
| === esv_ is now known as esv | ||
| falcojr | cjp256: I noticed your most recent PR references LP: #1958280. Is this the same issue as represented in the salesforce case, or is this a different issue? | 14:58 |
|---|---|---|
| ubottu | Launchpad bug 1958280 in cloud-init "Networking failures after NIC reordering" [High, Triaged] https://launchpad.net/bugs/1958280 | 14:58 |
| cjp256 | facojr: yeah i just opened it up as a draft to discuss as a workaround | 15:00 |
| cjp256 | falcojr: 18.04 / 20.04 / 22.04 are much happier without setting the names, just need to think through whether it is the right thing to do, even if temporary | 15:09 |
| falcojr | cjp256: so the name can be unpredictable between boots? I'm not sure that'd be any better | 15:23 |
| waldi | urgs, why does it emit "set-name" in the first place? | 15:27 |
| waldi | udev does not generate a predictable name for azure hv network devices. so every bets are off anyway | 15:29 |
| cjp256 | it emits it so there is a more predictable/consistent name, but it tends to cause some name thrashing on boot which sometimes leads to undesirable behavior with networkd | 15:35 |
| holmanb | cjp256: I'm getting up to speed on the issue. Just curious,do you know if there there is an eta on getting hv udev devices predictable? | 16:22 |
| cjp256 | holmanb: in which way? | 16:35 |
| holmanb | This is a workaround for hv names being unpredictable, but they should be predictable, right? | 16:37 |
| cjp256 | i ask because there are multiple aspects of this. (1) host ordering, or specifically guest enumeration and (2) imds configuration ordering which we rely on for netplan generation. we do have work slated to guarantee consistent ordering in IMDS to (today the only guarantee is that primary is first). there may be something else that I'm not aware of at lower levels? | 16:40 |
| holmanb | cjp256: Thanks for the additional context, I didn't have anything else in mind. I was wondering specifically about (1) - thanks | 16:44 |
| cjp256 | from what i've seen host ordering is reliably consistent, the problem is that IMDS is not. and we need them both to be consistent and matching to avoid the renames | 16:47 |
| cjp256 | though I think the failures due to renames need to be addressed regardless | 16:48 |
| blackboxsw | cjp256: this nic rename discussion and your active PR needs more understanding on our side I think. I think we need to spend a bit of time to fully understand the implications there. I'd like to try to address this after the 22.3 release if that is okay with you. | 18:30 |
| blackboxsw | I'd like to dig into the netplan component in the handling of the network config we write to understand if we just need something netplan-side instead | 18:31 |
| blackboxsw | no reason for cloud-init to jump through hoops if netplan is doing something undesireable with systemd | 18:32 |
| cjp256 | blackboxsw: agreed, not a good idea to try to drop something like this in for 22.3 at the last minute :D | 18:37 |
| cjp256 | probably should have stated that up front, sorry | 18:37 |
| cjp256 | i think 1672 would be fine which is why i broke it out, but also not required | 18:39 |
| blackboxsw | all good cjp256. we didn't think this was something to shoe-horn in, but wanted to set expectations that it'll be priority, but just not this week's release | 18:40 |
| oramirite | I have a bash tool that validates cloud config files as one of it's steps, and it seems like an upstream change recently broke things in two ways. I am trying to figure out where to find those upstream changes to assess what to fix on my end. The first issue, which I fixed, was that 'cloud-init devel schema' seems to have moved to 'cloud-init | 19:51 |
| oramirite | schema', because the documentation says not to script using devel commands (fair). Fixed that, but now the validation of a cloud config file I've used for years fails with the following error: "Cloud config schema errors: users.0: {<section values as a dict>} is not valid under any of the given schemas" | 19:51 |
| oramirite | Here are the changes I make to my config to get the validation working again. I'm very confused as to why the uid, groups and sudo fields don't seem to work anymore. As you can see form this link, commenting out all 3 fixes the issue. Adding any of them back in produces the validation error again: | 19:51 |
| oramirite | https://gist.github.com/oramirite/b9d19d0a05fa878044077c039654a7f7 | 19:51 |
| oramirite | Hoping someone can point me in the right direction to figure out what changed and why this validation is failing. I'm on Arch Linux. | 19:52 |
| blackboxsw | oramirite: great you are using cloud-init schema to validate.... let's take a look | 19:52 |
| blackboxsw | thx for the ping | 19:52 |
| oramirite | of course, thanks! | 19:52 |
| oramirite | Really hard to say when this started occurring btw, because I've come back to this script after about 3-4 months, and it's intended to be used from a live USB. So the most recent live media I built has this issue, hard to say exactly which version between now and 4 months ago is causing this. | 19:54 |
| blackboxsw | oramirite: so, your groups value is good, just your sudo needs to be a string instead of a list and uid needs to be an integer instead of a string | 19:55 |
| blackboxsw | oramirite: this schema changed to start being more strict in general, currently it only produces warnings in logs, but eventually our schema validation will be strict and result in errors. probably version 23.2 or later | 19:56 |
| oramirite | Okay so in theory this config will probably still work, the schema command is just warning me ahead of time basically? | 19:57 |
| blackboxsw | oramirite: https://github.com/canonical/cloud-init/blob/main/cloudinit/config/schemas/schema-cloud-config-v1.json#L159 is where the schema is defined for sudo | 19:57 |
| oramirite | I am in a little bit of a bind at the moment in that I need to use my script to deploy a system, but I don't know if my whole toolchain is now broken yet ;P | 19:57 |
| blackboxsw | oramirite: right, we still let those values pass currently as we want to give a good lead time before hard erroring on non-stict values | 19:57 |
| oramirite | very fair | 19:57 |
| blackboxsw | *non-strict* invalid schema values | 19:58 |
| oramirite | I figured all of this, good to have confirmation :) | 19:58 |
| oramirite | Is the documentation updated to reflect any of this yet? | 19:58 |
| oramirite | No worries if not, I think I was looking for confirmation there first is all and came up short | 19:58 |
| oramirite | ....wait, I think it totally is. Lol. | 19:59 |
| blackboxsw | oramirite: good pt, the schema cli is documented in the right place https://cloudinit.readthedocs.io/en/latest/topics/cli.html?highlight=schema#schema but not that we are warning and permissive on schema errors at the moment | 20:00 |
| blackboxsw | we probably could add a snippet in the tutorial about validating your cloud-init launch here https://cloudinit.readthedocs.io/en/latest/topics/tutorial.html | 20:00 |
| oramirite | https://cloudinit.readthedocs.io/en/latest/topics/modules.html#users-and-groups | 20:00 |
| blackboxsw | ohh right, yes all schema docs are rendered if that's what you were asking | 20:01 |
| oramirite | This is absolutely up to date, so I guess I was just brain farting when checking ha | 20:01 |
| oramirite | or just assumed what I had was fine | 20:01 |
| blackboxsw | complete with deprecation info "uid: (integer) The user’s ID. Default is next available value. DEPRECATED: The use of string type will be dropped after April 2027. Use an integer instead." | 20:01 |
| blackboxsw | all good. we like the feedback | 20:02 |
| blackboxsw | oramirite: note if you use VScode for anything as a dev platform, that you can manually try creating #cloud-config userdata by creating a file named `cloudconfig.yaml` or `*.cloudconfig.yaml` It'll then give tooltips on value types etc. | 20:06 |
| blackboxsw | oramirite: also https://www.jsonschemavalidator.net/ allows you to select schema type "cloud-init: cloud-config userdata JSON schema" to validate online | 20:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!