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:50 |
---|---|---|
dch | minimal: there are different network configs (LACP, multiple other types) and this needs to be statically provided pre-boot. | 00:51 |
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:52 |
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:53 |
blackboxsw | ^ taking that for my quote of the day wall | 00:54 |
minimal | blackboxsw ;-) | 00:54 |
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:00 |
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:01 |
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:04 |
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:05 |
blackboxsw | and I'm ignorant of terraform ... and will get there too | 01:08 |
meena | blackboxsw: I'll boot up an OpenBSD box and see if they have kenv to begin with, or something else entirely | 14:06 |
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:09 |
meena | i'm not seeing anything in OpenBSD's man pages for kenv or smbios | 14:10 |
blackboxsw | ok thanks | 14:17 |
meena | response (so far) from #openbsd: dont think so. closest would be eeprom, but that is for non-x86 machines | 14:19 |
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:20 |
blackboxsw | heh | 14:22 |
blackboxsw | ok so we could at least log a warning that no DMI variables supported currenty is is_OpenBSD() from read_dmi_data. | 14:23 |
meena | blackboxsw: you can always fall back to dmidecode | 14:30 |
meena | http://ports.su/sysutils/dmidecode | 14:30 |
meena | it's packaged | 14:30 |
=== nahamu_ is now known as nahamu | ||
Deckard111 | hey everyone! | 15:09 |
Deckard111 | I am looking for advice regarding usage of ninje template constructs in cfg files | 15:09 |
Deckard111 | Can i use a jinja expression like: | 15:12 |
Deckard111 | {% set test = '1' %} | 15:12 |
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:13 |
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:14 |
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:15 |
aciba | Deckard111: Hello! Do you have the error message? | 15:20 |
Deckard111 | @aciba Yes, see https://pastebin.com/HV4hD6Sr | 15:20 |
Deckard111 | cloud-init 22.3.4 | 15:23 |
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:24 |
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:25 |
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:27 |
Deckard111 | Sure, can do. | 15:28 |
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:30 |
aciba | how do you provide the cloud config? | 15:31 |
Deckard111 | latest ubuntu version - file at /etc/cloud/cloud.cfg.d/test.cfg | 15:32 |
Deckard111 | then run "cloud-init init" | 15:33 |
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:35 |
blackboxsw | lemme find that commit. | 15:36 |
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:37 | |
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:39 |
Deckard111 | yeah, my provider does not allow me to inject that beforehand | 15:40 |
Deckard111 | does it affect only /etc/cloud/cloud.cfg.d ? Would it work in /etc/cloud/cloud.cfg ? | 15:41 |
Deckard111 | (guess not) | 15:41 |
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:42 |
Deckard111 | Thank you for the help! | 15:43 |
blackboxsw | absolutely. I'm glad we had the foresight to add that feature. many folks have tried to do this in the past. | 15:44 |
Deckard111 | ok, have a nice day! | 15:46 |
Deckard111 | cya! | 15:46 |
falcojr | blackboxsw: probably not Monday or Tuesday. A bug was found that might slow things down | 16:01 |
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:03 | |
blackboxsw | grrr | 16:04 |
minimal | side question, does subiquity require cloud-init or is it an optional dep? | 16:09 |
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:12 |
minimal | blackboxsw: ok, saw it being used elsewhere and assumed it needed cloud-init | 16:14 |
=== Hi is now known as Guest8025 | ||
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:30 |
minimal | Guest8025: you installed OracleLinux and then on top of that installed the cloud-init package? | 16:33 |
Guest8025 | My kickstart config installes cloud-init | 16:34 |
minimal | Guest80254: ok, but does it not then configure things appropriately? | 16:34 |
minimal | are you installing cloud-init from an OracleLinux package or from upstream tarfile? | 16:35 |
Guest8025 | from the OracleLinux package. | 16:35 |
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:37 |
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:39 |
blackboxsw | ahh sorry I'm confusing it with an earlier offering then . | 16:40 |
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:41 |
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:42 |
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:43 |
blackboxsw | Guest8025: yes | 16:45 |
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:46 |
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 | 16:47 |
=== blackboxsw is now known as blackboxsw_away | ||
Guest8025 | blackboxsw: Thanks!! | 16:47 |
Guest8025 | Seems like that worked. Thanks a lot everyone! | 16:48 |
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:50 |
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 | 16:56 |
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:18 | |
blackboxsw_away | aciba: approved, feel free to use your merge rights and set the appropiate squash merged commit message. Thanks for the fast turnaround | 20:31 |
meena | anyway, time to get onto fixing bugs again | 22:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!