ani   any comment on https://github.com/canonical/cloud-init/pull/4291 ?06:57
-ubottu:#cloud-init- Pull 4291 in canonical/cloud-init "[RFC] NM renderer: set default IPv6 addr-gen-mode for all interfaces to eui64" [Open]06:57
Guest12does anyone know where I can find the source repo / how these builds are built for https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/ ?13:55
pemensik[m]Guest12: it does not have defined source git, but it the sourced page is: https://code.launchpad.net/~cloud-init-dev/cloud-init/+git/cloud-init/ SRPM can be fetched from: https://copr-dist-git.fedorainfracloud.org/cgit/@cloud-init/cloud-init-dev/cloud-init.git14:01
meenathe SRPM should have the info on where it's getting the sources from14:07
Guest12thanks pemensik[m] & meena - I think I'm starting to put it together looking at this - https://copr-dist-git.fedorainfracloud.org/cgit/@cloud-init/cloud-init-dev/cloud-init.git/tree/?h=epel914:09
pemensik[m]that copr repository has srpm uploaded to make a build. Therefore only owners knows how it is built exactly.14:40
pemensik[m]is there a more portable replacement for sudo cloud-init query ds?14:50
Guest12pemensik[m] - "Therefore only owners knows how it is built exactly." - not super helpful :')14:55
pemensik[m]Found /etc/network/interfaces rendered on my CentOS Stream 9. But haven't found any Network Manager attempt to configure it14:58
pemensik[m]is that error on Digital Ocean recipe or is the error in CentOS Stream distribution?14:58
Guest12pemensik[m] - that's exactly why I'm trying to figure out how to build it myself :')14:59
meenamine is built like this: https://codeberg.org/FreeBSD/freebsd-ports/src/branch/main/net/cloud-init-devel/Makefile14:59
meenawhen I bump the version, that's reflected there15:00
Guest12https://github.com/canonical/cloud-init/releases need at least `22.2` if I'm reading the release notes correctly15:00
minimalpemensik[m]: check /var/log/cloud-init.log to see which renderer(s) are being used for CentOS?15:00
pemensik[m]I don't understand cloud-init enough to know where to look.15:01
minimalpemensik[m]: I just told you the filename15:01
pemensik[m]https://src.fedoraproject.org/rpms/cloud-init might provide recent SRPM buildable on centos 915:01
pemensik[m] Selected renderer 'sysconfig' from priority list: None15:02
minimalso then cloud-init isn't/shouldn't be creating/modifying /etc/network/interfaces as that is done by the "eni" renderer15:03
pemensik[m]ah, shoot. /etc/sysconfig/network-scripts/ifcfg-eth0 is there also, it seems with good configuration. But is not used by version 9 anymore15:03
minimalfor Network Manager configuration then "network-manager" renderer should be used15:05
pemensik[m]is there way to recreate only network configuration from cloud-init, but leave ssh keys configured?15:05
minimalwhich ssh keys?15:06
pemensik[m]Original config has been created by 21.1-19.el9, but now I have cloud-init-23.1.1-7.el9.noarch15:06
pemensik[m]server ssh keys, as shown in /var/log/cloud-init-output.log ?15:07
minimalI assume you could set "ssh_deletekeys: false" in your user-data, clean up cloud-init and re-run it15:10
minimallooking at the cloud.cfg template, the default configuration for cloud-init on CentOS is to try to use these renderers (if supported) in order: sysconfig, eni, netplan, network-manager, networkd15:13
pemensik[m]just cleaned all anyway, but thanks. Will try next time15:16
minimalpemensik[m]: cloud-init treats all versions of CentOS in the same way. So, based, on what I said about default renderers list then CentOS Stream would need to be handled differently15:17
pemensik[m]minimal: do you know how it chooses which renderer to use? where is that specified?15:23
minimalbut it can be potentially overridden in other places (i.e. files in /etc/cloud/cloud.cfg.d/ directory)15:24
minimaloops, /etc/cloud/cloud.cfg15:25
minimalare you using a standard CentOS image that comes with cloud-init or did you/someone else create this image?15:26
pemensik[m]found in  /etc/cloud/cloud.cfg.rpmnew:      renderers: ['sysconfig', 'eni', 'netplan', 'network-manager', 'networkd' ]15:27
pemensik[m]original /etc/cloud/cloud.cfg does not contain renderers at all15:28
pemensik[m]I did not create anything, but the machine were created by my colleague. I have no direct access into Digital Ocean interface15:29
pemensik[m]I believe it should be stock CentOS15:29
minimalok, my question was "Is this an official CentOS image? or a DigitalOcean created/modified CentOS image? or created by someone else?"15:30
pemensik[m]I wish I know, sorry15:30
minimalas whomever created the image I'd expect to ensure it is configured appropriately15:30
pemensik[m]well it works and boots even this way. Not everyone wants ipv6 connectivity in their machines15:31
minimalsorry? I didn't mention IPv615:31
minimalso it is working? so what is the actual problem then?15:32
pemensik[m]at least from our internal openstack machines, centos 9 still chooses Selected renderer 'sysconfig' for some reason. 16:07
minimalright, because by default cloud-init uses a cloud.cfg for CentOS that has sysconfig specified as the 1st renderer to try and use16:11
bahamatIs there a way I can force detection of the datasource without doing any of the other stuff?17:57
bahamatI.e., I just want to have cloud-init tell me what it thinks the data source is.17:57
falcojrbahamat: /usr/lib/cloud-init/ds-identify --force, then check /run/cloud-init/cloud.cfg or /run/cloud-init/ds-identify.log18:00
falcojrpath may be different depending on your OS. If you use your package manager to list the files of cloud-init and the grep ds-identify, you can find it that way18:00
bahamatfalcojr: Thanks.18:01
meenanew release broke SmartOS datasource18:06
bahamatmeena: Yeah, I reported that bug. That's why I'm here.18:13
anankeI was wondering how I can force re-running of a specific module, specifically write_files. I'm trying to debug why on first boot I get errors, yet when I follow the procedure outlined here (https://stackoverflow.com/questions/23065673/how-to-re-run-cloud-init-without-reboot) to rerun everything, it works20:05
meenaananke: what are the errors?20:28
anankeThe error is cloud-init: TypeError: a2b_base64() argument 1 must be string or buffer, not None20:34
meenaand what does the trace look like? and the cloud-config?20:35
anankeit's hard to sanitize the data quickly, but the gist of it is that the write_files section is generated in part by AWS cloudformation. Eg, here's the part of CF template: https://dpaste.org/XrQPy20:38
anankeand the result is https://dpaste.org/tBs7q20:39
anankebase64 encoding is done on macos with base64 < inputfile. point being, there is actual value provided to the 'content: ' param20:40
anankewhat's interesting is that:20:41
ananke1) if the file with base64 encoding is first, then cloud-init throws that error20:42
ananke2) if the file with base64 encoding is second, then cloud-init throws no errors, but it creates only the first file20:43
anankeand if I run the 'sudo cloud-init clean --logs ; sudo cloud-init init --local20:44
anankeand if I run the 'sudo cloud-init clean --logs ; sudo cloud-init init --local ; sudo cloud-init init20:44
anankethe base64 file will be created20:44
anankebaffles me to no end. and the recipe/config used to work, last year. the only thing that changed now may be the newer version of the OS, because I point to /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 rather than specific ami ID20:46
anankehah. and it works now. it's one of those days, do something for N number of times, and somehow it fixes itself20:47
meenaweird 21:15
minimalananke: is this perhaps related to https://github.com/canonical/cloud-init/pull/4276 which was a base64-related handling issue that AWS has fixed in their AmazonLinux images but not in their AmazonLinux 2023 images?21:17
-ubottu:#cloud-init- Pull 4276 in canonical/cloud-init "ec2: Support double encoded userdata" [Open]21:17
minimalperhaps AWS have updated their AL2023 images now with that fix21:20
* meena is not paying enough attention 21:20

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!