[00:50] <minimal> dch: confused why you've disabled c-i network config - normally when you're using a metadata server you'd get network config from there
[00:51] <dch> minimal: there are different network configs (LACP, multiple other types) and this needs to be statically provided pre-boot.
[00:52] <minimal> doesn't packet's/equinix's metadata server provide for this?
[00:52] <minimal> so where's the network config coming from then?
[00:53] <dch> no, or perhaps more appropriately, the current implementation is provided in a previous stage, and we can "inherit" it on disk
[00:53] <minimal> strange, seems like a halfway house between NoCloud and something like Ec2
[00:54] <blackboxsw> ^ taking that for my quote of the day wall
[00:54] <minimal> blackboxsw ;-)
[01:00] <minimal> blackboxsw: BTW what's the story on 22.4.1? is it happening?
[01:00] <blackboxsw> dch per your ealier 'validation' for cloud-init ~ 1 year ago and mentioning things working.  I may be misreading... but beer in hand as I'm EOW now... so take what you will. Your /usr/local/etc/cloud/cloud.cfg.d/98_oci.cfg file is providing system config on disk, not user-data per-se. This gets acted upon by `users-groups` module during cloud-init's 'init' stage (not config:modules or config:final stages).
[01:00] <blackboxsw> dch:  so if you were only validating that default_user was observed, that'd only confirm that cloud-init's 'init' stage was run.
[01:01] <blackboxsw> which cloud-init config modules run during which stage is defined in /etc/cloud/cloud.cfg typically and user-groups lives under the cloud_init_modules: section (which is == 'init' boot stage)
[01:04] <dch> blackboxsw: no, the userdata scripts definitely worked, I used terraform & cloudinit to deploy labs of 30+ arm64 servers at EuroBSDcon
[01:04] <dch> thats still available so I can go back and see whats different
[01:05] <blackboxsw> ahh awesome, ok stand corrected.
[01:05] <dch> tomorrow, its 2am now here
[01:05] <blackboxsw> 'night
[01:05] <dch> I'm still very ignorant about cloudinit, I'll get there
[01:05] <blackboxsw> :)
[01:08] <blackboxsw> and I'm ignorant of terraform ... and will get there too
[14:06] <meena> blackboxsw: I'll boot up an OpenBSD box and see if they have kenv to begin with, or something else entirely
[14:09] <blackboxsw> no worries/rush at all meena, we can cope with other BSDs later. I was just touching the `cloudinit.dmi` module and wondered if I should have an initial warning if we were on BSD but not FreeBSD stating dmi lookup isn't set yet for this env.
[14:10] <meena> i'm not seeing anything in OpenBSD's man pages for kenv or smbios
[14:17] <blackboxsw> ok thanks
[14:19] <meena> response (so far) from #openbsd: dont think so. closest would be eeprom, but that is for non-x86 machines
[14:20] <meena> which is ironic, because I migrated cloud-init on FreeBSD away from dmidecode because it was super dodgy on non-x86, with the additional advantage of dropping a giant dependency and working on more platforms that we do on Linux
[14:20] <meena> *theoretically working on more platforms
[14:22] <blackboxsw> heh
[14:23] <blackboxsw> ok so we could at least log a warning that no DMI variables supported currenty is is_OpenBSD() from read_dmi_data.
[14:30] <meena> blackboxsw: you can always fall back to dmidecode
[14:30] <meena> http://ports.su/sysutils/dmidecode
[14:30] <meena> it's packaged
=== nahamu_ is now known as nahamu
[15:09] <Deckard111> hey everyone!
[15:09] <Deckard111> I am looking for advice regarding usage of ninje template constructs in cfg files
[15:12] <Deckard111> Can i use a jinja expression like:
[15:12] <Deckard111> {% set test = '1' %}
[15:13] <Deckard111> in a YAML cfg file?
[15:13] <Deckard111> I use the correct headers:
[15:13] <Deckard111> ## template: jinja
[15:13] <Deckard111> #cloud-config
[15:14] <Deckard111> still the set line is shown as error
[15:14] <Deckard111> using normal variables like {{ ds.meta_data.local_hostname }} works like a charm, though
[15:15] <Deckard111> so, maybe it is only possible to use plain variables from jinja ? no language constructs?
[15:15] <Deckard111> Any hint would be very much appreciated.
[15:20] <aciba> Deckard111: Hello! Do you have the error message?
[15:20] <Deckard111> @aciba Yes, see https://pastebin.com/HV4hD6Sr
[15:23] <Deckard111> cloud-init 22.3.4
[15:24] <aciba> The use of jinja templates in instance-data is documented here: https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html#what-is-instance-data, and in cloud-cfg here: https://cloudinit.readthedocs.io/en/latest/topics/format.html#cloud-config-data
[15:25] <aciba> Deckard111: I do not see anything wrong with that config. To me that sounds like a bug. Would you mind reporting it? More info: https://cloudinit.readthedocs.io/en/latest/topics/bugs.html
[15:27] <Deckard111> Yeah, so I basically want to us a construct like https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html#user-data-script-with-instance-data in a config file
[15:28] <Deckard111> Sure, can do.
[15:30] <aciba> Yeah, by reading the docs, I would not assume that the use of `set` is forbidden. And even if that would be the case, an UnicodeError would also be a bug, from my understanding.
[15:30] <Deckard111> I would expect the jinja compiler to run before the normal yaml interpreter
[15:31] <aciba> how do you provide the cloud config?
[15:32] <Deckard111> latest ubuntu version - file at /etc/cloud/cloud.cfg.d/test.cfg
[15:33] <Deckard111> then run "cloud-init init"
[15:35] <blackboxsw> aciba: Deckard111 yeah that config looks good to me check this paste note you can use cloud-init devel render to test out your jinja file content  https://paste.opendev.org/show/biwMariqPXkiWrxY92mZ/
[15:35] <blackboxsw> Ahh Deckard111 so the ability to provide jinja content in /etc/cloud/cloud.cfg.d only recently landed 
[15:36] <blackboxsw> lemme find that commit.
[15:37] <blackboxsw> https://github.com/canonical/cloud-init/commit/197cc8ccb9d2b9856456ed2e2a5cb4748df5ec0f which would be in 22.3-35 or later for cloud-init
[15:37] -ubottu:#cloud-init- Commit 197cc8c in canonical/cloud-init "Allow jinja templating in /etc/cloud (SC-1170) (#1722)"
[15:39] <blackboxsw> which is not released yet into any downstream ubuntu release
[15:39] <Deckard111> ah ok
[15:39] <Deckard111> that explains it
[15:39] <Deckard111> yeah "cloud-init devel render" say it is all fine
[15:39] <blackboxsw> Deckard111: but this could be provided as user-data during vm/container launch (instead of on the filesystem)
[15:40] <Deckard111> yeah, my provider does not allow me to inject that beforehand
[15:41] <Deckard111> does it affect only  /etc/cloud/cloud.cfg.d ? Would it work in  /etc/cloud/cloud.cfg ?
[15:41] <Deckard111> (guess not)
[15:42] <blackboxsw> the commit is to add jinja support for both /etc/cloud/cloud.cfg and /etc/cloud/cloud.cfg.d together because neither supported that 'yet'. That said we have queued our release of 22.4 that we expect to be able to publish Mon/Tuesday of next week for Ubuntu 18.04, 20.04, 22.04, 22.10. So new cloudimages for ubuntu will have this support shortly
[15:42] <Deckard111> awesome, then I will be patient ;)
[15:43] <Deckard111> Thank you for the help!
[15:44] <blackboxsw> absolutely. I'm glad we had the foresight to add that feature. many folks have tried to do this in the past.
[15:46] <Deckard111> ok, have a nice day!
[15:46] <Deckard111> cya!
[16:01] <falcojr> blackboxsw: probably not Monday or Tuesday. A bug was found that might slow things down
[16:03] <falcojr> https://bugs.launchpad.net/bugs/1997559
[16:03] -ubottu:#cloud-init- Launchpad bug 1997559 in cloud-init (Ubuntu) "AttributeError: 'NoneType' object has no attribute 'partition'" [Undecided, New]
[16:04] <blackboxsw> grrr
[16:09] <minimal> side question, does subiquity require cloud-init or is it an optional dep?
[16:12] <blackboxsw> minimal: subiquity does require cloud-init and bakes it into the snap. it's used as the primary mechanism to apply configuration to the target machine
[16:14] <minimal> blackboxsw: ok, saw it being used elsewhere and assumed it needed cloud-init
=== Hi is now known as Guest8025
[16:30] <Guest8025> I installed OracleLinux 8 (OL8) and cloud-init is picking 'ubuntu' as the distro.  Are there any tips on where to look to tell cloud-init that this distro is rhel-based?
[16:30] <Guest8025> # tail /etc/cloud/cloud.cfg
[16:30] <Guest8025> system_info:
[16:30] <Guest8025>   distro: ubuntu
[16:33] <minimal> Guest8025: you installed OracleLinux and then on top of that installed the cloud-init package?
[16:34] <Guest8025> My kickstart config installes cloud-init
[16:34] <minimal> Guest80254: ok, but does it not then configure things appropriately?
[16:35] <minimal> are you installing cloud-init from an OracleLinux package or from upstream tarfile?
[16:35] <Guest8025> from the OracleLinux package.
[16:37] <minimal> ok, I would have expected the maintainer of cloud-init for OracleLinux to have set things up appropriately
[16:37] <Guest8025> Which is why I suspect I might be doing something wrong -- I just have no idea where to look. :(
[16:39] <minimal> in fact I'm not even sure if cloud-init "knows" about Oracle as a distro. It's a RHEL/CentOS/etc derivative right?
[16:39] <Guest8025> I looked at cloud-init's code and I can see that if it cannot determine the distro, it falls back to ubuntu.  Beyond that, I am not sure how to see if OL modified cloud-init to add OL support or not.
[16:39] <Guest8025> Yes.
[16:39] <Guest8025> OL is a RHEL deriative.
[16:39] <blackboxsw> minimal: Guest8025 Oracle Linux has an older version of cloud-init on it because it's py2.7 based I think?
[16:39] <Guest8025> python 3.6 is the default in OL8.
[16:40] <blackboxsw> ahh sorry I'm confusing it with an earlier offering then .
[16:41] <Guest8025> cloud-init 22.1-5 is installed.
[16:41] <minimal> Guest8025: so normally I'd expect the OL packager/maintainer to have set "distro: " in /etc/cloud.cfg appropriately. As cloud-init doesn't currently know about OL I'm not sure what that could be set to currently
[16:41] <blackboxsw> historically Oracle folks had a couple of minor downstream distro patches applied to cloud-init, but generally I'd expect it to track pretty closely with what cloud-init upstream has offered
[16:42] <Guest8025> minimal: There is no /etc/cloud.cfg -- I do see a /etc/cloud/cloud.cfg. Are those the same?
[16:42] <blackboxsw> yes and per minimal's comment, the image creators/maintainers themselves are typically responsible for generating either the /etc/cloud/cloud.cfg file or supplemental /etc/cloud/cloud.cfg.d/ needed to override defaults for the upstream project
[16:42] <blackboxsw> I think the paths were off in minimal's comment should be under /etc/cloud
[16:43] <Guest8025> Can I drop a file in /etc/cloud/cloud.cfg.d/ with distro: rhel or something like that to change the default?
[16:43] <minimal> sorry, yes, forgot the path
[16:45] <blackboxsw> Guest8025: yes
[16:46] <blackboxsw> cat > /etc/cloud/cloud.cfg.d/setdistro.cfg << EOF
[16:46] <blackboxsw> system_info:
[16:46] <blackboxsw>  distro: centos
[16:46] <blackboxsw> EOF
[16:47] <blackboxsw> sudo cloud-init clean; sudo cloud-init init --local; grep distro /var/log/cloud-init.log  # <- this is destructive to your current instance BTW
[16:47] <blackboxsw> gotta head out
=== blackboxsw is now known as blackboxsw_away
[16:47] <Guest8025> blackboxsw: Thanks!!
[16:48] <Guest8025> Seems like that worked.  Thanks a lot everyone!
[16:50] <minimal> Guest8025: Oracle seems to have tooling here: https://github.com/oracle-linux/oracle-linux-image-tools/ to create VM images for various clouds. I guess somewhere in there they must be adapting cloud.cfg
[16:56] <minimal> they install cloud-init and set some config here: https://github.com/oracle-linux/oracle-linux-image-tools/cloud/oci/provision.sh  but nothing about distro
[20:18] <aciba> PR addressing lp1997559: https://github.com/canonical/cloud-init/pull/1876
[20:18] -ubottu:#cloud-init- Pull 1876 in canonical/cloud-init "status: handle ds not defined in status.json" [Open]
[20:31] <blackboxsw_away> aciba: approved, feel free to use your merge rights and set the appropiate squash merged commit message. Thanks for the fast turnaround
[22:16] <meena> anyway, time to get onto fixing bugs again