[17:28] <redkrieg> Thanks for merging my PR to fix the user groups in cloud-config data.  Just out of curiosity, is this likely to make it in to official images for 22.04?  I'm having to use a custom image for my clients right now as a workaround and I would prefer to offer official images.
[17:32] <falcojr> redkrieg: it will eventually, but not until end of August or early September. Since this only results in a schema warning in the logs and not any functional breakage, it doesn't justify a hotfix release
[17:35] <redkrieg> Well, it does result in previously functional cloud-config files breaking, but I get that regressions like that where a workaround exists are probably not high priority.
[17:35] <redkrieg> I only learned about it because a customer couldn't get their cloud-config to work and the example came right from my knowledge base.
[17:37] <redkrieg> The same cloud-config sets up users as expected on 20.04 images.
[17:37] <redkrieg> Just not 22.04
[17:40] <falcojr> redkrieg: do you have an example of something that did work before but does not anymore? Schema validation errors shouldn't lead to anything breaking. It is currently not strict validation and only results in a warning in the logs
[17:40] <falcojr> so if something has become actively broken, that might require a separate fix
[17:45] <redkrieg> falcojr: on 22.04 https://paste.ubuntu.com/p/zfZkdxXYzg/ does not create a user, but https://paste.ubuntu.com/p/hvgCfpY932/ does.  give me a few and I'll get output from the actual console when it fails on 22.04
[17:45] <redkrieg> both work on 20.04
[17:46] <falcojr> I'll try it locally, thanks
[17:53] <redkrieg> just got the output for both, starting with cloud-init https://paste.ubuntu.com/p/7nVZQXR9ww/
[17:59] <falcojr> are they checking for that warning, or are they actually preventing from logging in?
[17:59] <falcojr> I'm seeing https://paste.ubuntu.com/p/f6JFG5XMp3/
[17:59] <falcojr> which has the warning, but is still just as functional
[18:00] <falcojr> that was a strangely worded question...let me try again. Are they failing because they're checking for warning/error and failing automatically if they see one? Or are they actually prevented from logging in?
[18:02] <redkrieg> they are prevented from logging in when that warning appears.  if you check my output you can see the ssh authorized key is only listed on the successful one.  I'm wondering if it does create a user and just skips the key maybe?  I'll have to try setting a password on one
[18:02] <redkrieg> I assumed it wasn't made at all since I was unable to ssh in with the key provided
[18:03] <redkrieg> at the very least it's not completely configuring the user as expected
[18:04] <redkrieg> (checking now to see if it's partial or not).  I'm testing with the ubuntu cloud server image release from 20220622
[18:09] <redkrieg> well, now I'm feeling pretty stupid because I can't replicate it with the same cloud config I gave you.  the initial complaint was that the cloud config wasn't working, my example is pretty much what my user was using but with my info swapped in.  I definitely replicated being unable to log in Friday.  I'm definitely feeling crazy right now
[18:09] <redkrieg> sorry for taking your time like this
[18:10] <falcojr> happens all the time in software :P No problem at all. I just hope there isn't a related problem that's still lurking. Let me know if you find anything else!
[18:12] <redkrieg> will do, thanks for the time
[19:55] <redkrieg> I finally figured out what was happening.  One of my switches was not passing multicast traffic, so instances spawned in that cabinet were not able to get metadata.  My failing instances just happened to be launched there and I didn't have the image properties set to use config disk, which would've bypassed the problem.
[19:56] <redkrieg> The schema validation warning was completely unrelated to my issue all along, but I am glad I was able to fix it anyway.