=== paride|off is now known as paride
[11:35] <testmad> I need help. Currently trying to use cloud-init on Azure VMs in vmss.  Testing my cloud-config is fine and I am able to SSH into the vm and verify packages are installed, files created, etc. When I add a users block to my config I am no longer able to SSH into the VM.  Has anyone experienced something like this?  Could my users block be overwriting an existing one that is being supplied?
[12:24] <meena> testmad: what's your user-data look like?
[12:35] <testmad> meena: right now its a few write-files, packages, and runcmds.
[12:35] <testmad> It all works fine
[12:36] <testmad> If I add -name: foo under a users: block that is when I can no longer SSH into the VM
[12:37] <meena> testmad: can you please pastebin the working vs the non-working state?
[12:39] <testmad> I do not believe I would be allowed to do that.
[12:40] <testmad> give me a moment ad I can provide something similar.
[12:47] <testmad> meena: working - https://pastebin.pl/view/ca40b3ae and not working - https://pastebin.pl/view/29192b4c
[12:54] <testmad> Also in case it matters, this is on azure vmss using the ubuntu 16.04 image
[13:10] <meena> testmad, that looks like it should just work.ii wonder if we have a validation option inthe cli
[13:14] <absc> Hi
[13:15] <absc> I'm the same guy that had a problem configuring the network using cloud-init on CentOS converted to CloudLinux
[13:15] <absc> meena: We found the problem
[13:19] <testmad> meena, there is a way. cloud-init devel schema --config-file <path/to/file>
[13:19] <testmad> and both the working and non-working come back valid
[13:21] <chillysurfer> testmad: we need to see logs to understand what is happening. you can use this method to get access to the logs: https://trstringer.com/recovery-os-disk-azure-linux-vm/
[13:21] <chillysurfer> likewise you can try to serial console into the machine and dig around there
[13:22] <absc> It seems that cloud-init doesn't like the content cloudlinux put in /etc/os-release
[13:23] <absc> Changing the file with a stock CentOS 8.2 one, confirm the problem. After that, the network configuration is completed successfully.
[13:23] <absc> I don't know who's doing the wrong thing tho...
[13:25] <meena> absc: can you still submit a bug report?
[13:26] <absc> meena: Yep, I already did it and I updated it with the new informations. https://bugs.launchpad.net/bugs/1894990
[13:26] <ubot5> Ubuntu bug 1894990 in cloud-init "Fail to configure a Centos 8 machine with cloudlinux" [Undecided,Triaged]
[13:33] <meena> absc: so we need a CloudLinux distro then, like this: https://github.com/canonical/cloud-init/pull/510
[13:33] <absc> I think so?
[13:34] <absc> Unless cloud-init doesn't start to use the field ID_LIKE as a backup
[13:34] <absc> When it doesn't recognize the distribution in it's list
[13:36] <meena> oy
[13:36] <absc> I'm not sure what the proper solution is
[13:37] <meena> it might be simpler to use hat field, than to keep adding distro classes which do almost nothing
[13:49] <absc> For sure
[14:57] <testmad> meena, chillysurfer : I may have solved my problem. Adding - default to my user block lets me SSH in again. But now I have another question.. How can I write_files and set the owner to the user i am adding in the user block? It seems as though it's not possible since write_files is done before users-groups.
[15:01] <meena> testmad: you'd have to change the order in cloud.cfg
[15:12] <testmad> Re: user block problem.. it does seem that my user block is overwriting the user block being passed in from azure and also my attempts at changing the merge behavior to append is not working either
[15:24] <Krikke> I just did runcmd and chmod :x
[16:44] <blackboxsw> falcojr: nice verification on the grub fix. I think we just need to attach those verification logs to the related bug
[16:46] <blackboxsw> and you can change the verification-needed-X tags to verification-done-X on that grubbug
[16:46] <blackboxsw> falcojr: also the SRU bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1893064 I think we are missing a confirmation of cdoqa results (which I think completed successfully)
[16:46] <ubot5> Ubuntu bug 1893064 in cloud-init (Ubuntu) "sru cloud-init (20.2-45 to 20.3-2) Xenial, Bionic, and Focal" [Undecided,In progress]
[16:48] <blackboxsw> so we need to get jog or someone from CDO QA/solutions QA to link the verifcation results to the SRU bug. and we can and should ping the SRU vanguard in #ubuntu-release channel that we are ready for SRU upload review into Xenial/Bionic/Focal
[16:50] <falcojr> blackboxsw what do you mean by link those verification logs to the related bug?
[16:53] <blackboxsw> falcojr: so our current SRU has two bug ids associated with it as seen in the cloud-init rows @ https://people.canonical.com/~ubuntu-archive/pending-sru.html
[16:54] <blackboxsw> in order to ping ubuntu-release SRU vanguard, we need to attach relevant verification logs to each SRU bug.
[16:54] <blackboxsw> one bug is the SRU process bug (to which we've attached all our manual cloud verification/maas  logs
[16:55] <blackboxsw> the other is that specific grub bug, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1889555
[16:55] <ubot5> Ubuntu bug 1889555 in cloud-init (Ubuntu Groovy) "cc_grub_dpkg was fixed to support nvme drives, but didn't clear the state of cc_grub_dpkg and didn't rerun it on upgrades" [Undecided,In progress]
[16:55] <blackboxsw> to which you'll need to upload your  logs/test output from https://github.com/cloud-init/ubuntu-sru/pull/145
[16:56] <blackboxsw> because that specific bug is called out in the debian/changelogs of our SRU upload
[16:59] <blackboxsw> one other requirement for the SRU generally is to update the description of the bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1889555 with an SRU verification template
[16:59] <ubot5> Ubuntu bug 1889555 in cloud-init (Ubuntu Groovy) "cc_grub_dpkg was fixed to support nvme drives, but didn't clear the state of cc_grub_dpkg and didn't rerun it on upgrades" [Undecided,In progress]
[17:01] <blackboxsw> falcojr: I'll update that bug description now with something like this https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
[17:01] <blackboxsw> which I'm just going to adapt from your original test plan header from  https://github.com/cloud-init/ubuntu-sru/pull/145
[17:02] <blackboxsw> or actually  cut-n-paste. no adapting needed really
[17:04] <falcojr> Makes sense. Thanks
[17:04] <blackboxsw> so I'll let you upload your full SRU test log on that one.
[17:05] <blackboxsw> and then replace any verification-needed* tags with verification-done*
[17:05] <blackboxsw> that'll turn the bug id link from yellow to green on https://people.canonical.com/~ubuntu-archive/pending-sru.html
[17:36] <falcojr> blackboxsw we should merge the issue in github first, right?
[17:37] <falcojr> I just responded to your comment. Is it good to merge?
[17:50] <blackboxsw> oops, yes merging  now and you can cut-n-paste logs the the bug
[17:50] <blackboxsw> merged falcojr
[17:52] <falcojr> lol, right as Dan had a comment
[17:53] <blackboxsw> heh. comment wasn't in my view  as I merged. ahh well. could push the typo changes. if you do that you can also redact the "ls blk" typo too
[17:59] <Odd_Bloke> I leave for *checks watch* 5 hours and you're merging things without reading my comments smh. ;)
[18:00] <falcojr> haha, that was good timing!
[18:01] <falcojr> blackboxsw I attached the log and updated the tags on that bug
[18:01] <Odd_Bloke> testmad: You're correct that write_files runs before user/group creation: we can't modify this order because people will be relying on it in the wild (the canonical example we use is writing something to /etc/skel; if we changed the order, then user creation would change under people).  You can reorder the modules on your own system, but a better solution may be to write them out in a runcmd block.
[18:01] <blackboxsw> hah
[18:02] <blackboxsw> "Odd_Bloke's stepped away from the keyboard" full steam ahead. It's cowboy time
[18:02] <Odd_Bloke> We have had conversations about adding a later write_files stage, so we can continue to support existing users as well as your use case, but that hasn't been more than talk yet IIRC.
[18:25] <falcojr> blackboxsw: so at this point we can change the tags on that other bug too, right?
[18:25] <falcojr> and ping the vanguard, you mentioned doing that...or should I do it or has it been done already?
[18:25] <falcojr> sorry, can't video atm
[18:34] <blackboxsw> falcojr: if we have a confirmation form solutionsqa on https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1893064
[18:34] <ubot5> Ubuntu bug 1893064 in cloud-init (Ubuntu) "sru cloud-init (20.2-45 to 20.3-2) Xenial, Bionic, and Focal" [Undecided,In progress]
[18:34] <blackboxsw> I think that is the only thing missing
=== hjensas is now known as hjensas|afk
[21:12] <meena> Odd_Bloke, i… don't know how to ask people from OpenNebula anything
[21:12] <meena> there's… no IRC channel
[21:12] <meena> so, 🤷🏻‍♀️