[12:28] <Ally_> Hello, hope everyone is well. I don't suppose anyone can advise if there's a way to set the order of packages to be installed when specifying them in the YAML custom script? I want to install 'ansible' but I need to install 'oracle-epel-release-el7' first, putting it first still seems to get ignored, I imagine it does it alphabetically or similar?
[12:29] <Ally_> Or, should I just do it with a runcmd instead?
[12:42] <aciba> Ally: There is an undocumented (atm) way to do that using https://cloudinit.readthedocs.io/en/latest/topics/merging.html. Maybe falcojr could help you.
[13:21] <Ally_> Thanks aciba, much appreciated!
[14:33] <falcojr> Ally_: when you say order of packages to be installed, are you referring to using the 'packages' key in cloud-init userdata? E.g., packages: ['oracle-epel-release-el7', 'ansible']
[14:33] <falcojr> or something else?
[15:19] <Ally_> Hi falcojr, yep
[15:20] <falcojr> Ally_: that behavior is distro-dependent. Which distro?
[15:20] <Ally_> We're using OEL 7.9
[15:22] <Ally_> I've worked around it by doing it via runcmd, but I assumed there was a 'smarter' way by using the native package command
[15:22] <falcojr> hmmm, do you know if that gets identified as RHEL by cloud-init, or do you have some custom code for identifying that?
[15:22] <Ally_> It should identify as RHEL (it's a clone)
[15:23] <Ally_> Is there a quick way to determine how cloud-init sees it?
[15:24] <blackboxsw> Ally_: I think cloud-init query distro
[15:25] <falcojr> blackboxsw: TIL! I would've said search the logs
[15:25] <Ally_> thanks blackboxsw
[15:25] <blackboxsw> otherwise grep "Using distro class" /var/;log/cloud-init.log would cofirm
[15:25] <blackboxsw> right
[15:25] <Ally_> # cloud-init query distro
[15:25] <Ally_> ERROR: Undefined instance-data key distro
[15:26] <blackboxsw> ahh OEL 7.9 ... older cloud-init based on version 19.3 or something right 
[15:26] <Ally_> # grep "Using distro class" //var/log/cloud-init.log
[15:26] <Ally_> 2022-09-09 13:19:43,979 - stages.py[DEBUG]: Using distro class <class 'cloudinit.distros.rhel.Distro'>
[15:26] <blackboxsw> cool that worksthx
[15:26] <Ally_> Cloud-init v. 19.4
[15:27] <falcojr> Ally_: so actually, it looks like regardless of distro it orders them in the way they were specified. But it does it with a single command. Are you looking for multiple, independent commands for installation?
[15:29] <Ally_> Umm, no, not really. To install 'ansible' package it needs the EPEL repo enabled, and that's an RPM install on OEL. So I specified the epel package first in the list of packages and 'ansible' second, but when it ran it tried to install the 'ansible' package first.
[15:31] <Ally_> https://pastebin.com/UVrFbJFj
[15:31] <Ally_> That's what I was trying to get to work
[15:33] <Ally_> I kinda assumed it was doing like a hoist in JS and running things alphabetically or something
[15:34] <waldi> Ally_: you are looking for yum_repos, which asks cloud-init to add repos
[15:34] <waldi> cloud-init will of course not install packages one after one, but everything in one go
[15:35] <Ally_> Ah, ok, I think I see what you mean. So if I enable the EPEL using the yum_repos command I can skip the epel package part altogether.
[15:35] <waldi> yes
[15:35] <Ally_> I will test that now, thank you waldi (and everyone else!)
[16:12] <blackboxsw> note Ally_ you are specifying `ansible:` config in cloud-init but you are running cloud-init version 19.4 on OEL.... `ansible:`  support in cloud-init was only added after cloud-init version 22.2 so you'll probably have to use individual `runcmd:`declarations to perform that setup of ansible in your distro.
[16:13] <blackboxsw> as I recall, python version on OEL is python2.7 right? which means that OEL systems won't be able to install and run anything beyond 19.4 unless they also happen to have python3 configured
[16:18] <Ally_> Ah, that's good to know, thank you!
[16:24] <blackboxsw> note we have a copr build repo https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-testing/ that may help wih EL8-based images if you have them 
[16:24] <blackboxsw> it contains cloud-init 22.3
[17:57] <cjp256> blackboxsw/falcojr: any thoughts what may be happening here? https://pastebin.ubuntu.com/p/kDc5ZKRZVs/
[17:57] <cjp256> holman^
[17:58] <cjp256> (search for first hit of iid-datasource)
[18:01] <blackboxsw> looking
[18:02] <cjp256> get_data() is also called twice, init-local and init
[18:03] <blackboxsw> strange mid-init stage iid-datasource shows up
[18:05] <cjp256> this is on upgrade from 22.2 -> 22.3 in proposed
[18:05] <cjp256> thought maybe it was that recent cache change but I reverted it and didn't seem to change that
[18:07] <blackboxsw> cjp256: so iid-datasource comes into play when cloud-init no longer sees "instance-id" in the cached metadata that was read
[18:08] <blackboxsw> I'd be curious if something between init-local and init stage blew away self.metadata on the obj.pkl
[18:08] <cjp256> yeah, it should be there - i lost a debug log, i'll retry
[18:38]  * blackboxsw takes a break from internal work and starts plugging away at Azure upgrade path on -proposed to see what's up there
[18:40] <falcojr> ^ I would normally jump in to help, but I'm guessing it's a welcome break :P
[18:40] <holman> cjp256: what's puzzling me is that you said building from tag 22.3.1 didn't cause the same issue 
[18:41] <holman> otherwise I'd guess that the self._reported_ready_marker_file addition not being unpickled as a likely cause
[18:46] <cjp256> I take that back, I think it may have been because I went from the proposed deb to the custom one?
[18:46] <cjp256> i retried that today and it did repro
[18:46] <cjp256> from a fresh 22.2
[18:47] <holman> 22.2->22.3.1 repro'd the issue?
[18:47] <cjp256> yeah the current image 22.2-0ubuntu1~22.04.3
[18:47] <holman> gotcha
[18:48] <cjp256> i'll resume looking into it monday, have a good weekend! :D
[18:48] <holman> yeah I'm pretty sure there's an issue on unpickle here, since _reported_ready_marker_file won't exist in 22.2 pickles,
[18:48] <holman> cjp256: You too!
[19:31] <falcojr> holman: we should figure out why the upgrade integration test didn't catch this. Do you need help digging into that?
[19:32] <holman> @falcojr: Saw your comment on the PR, I'm looking at that now. I should be more familiar with this and I've never touched it, so I'll reach out if I need help. 
[19:47] <holman> @falcojr: looks like test_upgrade in SRU testing used an image_id: Canonical:0001-com-ubuntu-server-jammy-daily:22_04-daily-lts
[19:47] <holman> Daily images would have compatible pickles I think.
[19:50] <falcojr> holman: it's not the daily ppa. It's the daily cloud image. I wouldn't expect it to launch with that property, so it shouldn't be in the pickle at upgrade
[19:51] <falcojr> i.e., I would expect Canonical:0001-com-ubuntu-server-jammy-daily:22_04-daily-lts to be providing 22.2, then the upgrade test upgrades to 22.3 proposed
[19:57] <holman> falcojr: I see, thanks.
[19:58] <holman> tangentially related, I see that the ubuntu cloud-image locator website isn't aware of the existence of Jammy images.
[19:59]  * holman goes back to digging into the test
[19:59] <holman> s/Jammy images/Jammy images on Azure/g
[21:26] <CorvetteZR1> hello.  how do i edit an existing cloud-init config?
[21:27] <CorvetteZR1> i set up a mount with noexec option.  i removed it manually from fstab and remount; but when i reboot the server, i see noexec in fstab again.  how can i modify it in cloudinit, so when it overwrites fstab, it no longer applies noexec ?
[21:27] <CorvetteZR1> without reprovisioning whole server i mean
[21:59] <holman> @falcojr - not sure if you're still around, but I did a brain-dump of my working theory in that PR.
[22:00] <falcojr> holman: cool. I'll take a look (maybe Monday)
[22:00] <holman> @falcojr sweet, no rush
[22:02] <holman> CorvetteZR1: What's your config look like? cc_mounts runs once per instance, so running every boot is not expected. More information in general about your setup would help a lot :)
[23:31] <blackboxsw> holman: you are totally right on cjp256's Azure upgrade bug. it is unpickling problem across upgrade given that the obj.pkl doesn't have the _. the following patch fixes it https://paste.ubuntu.com/p/4yybCvHgvp/
[23:32] <blackboxsw> I'll put up a PR and set you both as reviewers
[23:32] <blackboxsw> this will block SRU