[06:18] <otubo> blackboxsw: thanks a lot for the info. Looks safe to drop python-jsonschema from our point of view. :)
[07:18] <JRodDynamite> Hey, how can I make `bootcmd` commands get executed by a different user other than root?
[16:38] <blackboxsw> falcojr: +1 on https://github.com/canonical/cloud-init/pull/901#pullrequestreview-663422200 one minor question
[16:39] <blackboxsw> JRodDynamite: something like this would work #cloud-config\nbootcmd:\n- su - ubuntu -c 'touch /var/tmp/somefile-as-ubuntu'\n
[16:49] <chillysurfer> hey, all! trying to run integration tests and specify a particular azure image. i set CLOUD_INIT_OS_IMAGE='<azure_image_identifier>' but it still seems to default to something else
[16:49] <chillysurfer> any way to change that?
[16:50] <chillysurfer> it picks up my desired image - integration_testing:clouds.py:84 Detected image: image_id=Canonical:UbuntuServer:18.04-LTS:latest os=ubuntu release=bionic
[16:50] <chillysurfer> but then defaults to a completely different images - image_id=Canonical:0001-com-ubuntu-pro-bionic-fips:pro-fips-18_04:18.04.202010201
[16:50] <chillysurfer> s/images/image/
[16:50] <chillysurfer> not sure what i'm doing wrong..?
[16:54] <chillysurfer> ah nevermind
[16:55] <chillysurfer> looks like the integration test forces this image urn
[17:08] <blackboxsw> ahh chillysurfer yeah that particular integration test was only exercising LP #1835584 which was most easily reproducible using a FIPS kernel. If your CI runs want to avoid that test or disable it or adapt it so we don't use a PRO image to exercise that logic, we can definitely work to make that avoid PRO images.
[17:08] <blackboxsw> falcojr: landed  https://github.com/canonical/cloud-init/pull/901#pullrequestreview-663422200  thx
[17:08] <falcojr> Thanks
[17:09]  * blackboxsw almost. oops waiting on CI. too soon on the msg, but within a couple mins
[17:15]  * blackboxsw nice Rocky linux supprt PR . Woot. https://github.com/canonical/cloud-init/pull/906 I'll grab that for review/shepherding
[18:56] <falcojr> curious if we've ever seen a datasource get detected and the generator enable the target unit, but not all of the services being enabled
[18:56] <falcojr> https://bugs.launchpad.net/cloud-init/+bug/1928603
[18:57] <falcojr> we get to the network stage and then just stop...based on whats in /etc/systemd/system, it looks like there's no services to run the next stages
[22:49] <rharper> falcojr: that bug  opensuse, that smells like vmware guest-tools conflicts ;  there's a really long history of vmware guest tools racing/mucking with cloud-init for various reasons;  cpaelzer knows this very well;  so my first request in the bug is if it's reproducible without vmwaretools active; (and I suspect not);