[06:57] <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]
[13:55] <Guest12> does 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/ ?
[14:01] <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.git
[14:07] <meena> the SRPM should have the info on where it's getting the sources from
[14:09] <Guest12> thanks 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=epel9
[14:40] <pemensik[m]> that copr repository has srpm uploaded to make a build. Therefore only owners knows how it is built exactly.
[14:50] <pemensik[m]> is there a more portable replacement for sudo cloud-init query ds?
[14:55] <Guest12> pemensik[m] - "Therefore only owners knows how it is built exactly." - not super helpful :')
[14:57] <minimal> portable?
[14:58] <pemensik[m]> Found /etc/network/interfaces rendered on my CentOS Stream 9. But haven't found any Network Manager attempt to configure it
[14:58] <pemensik[m]> is that error on Digital Ocean recipe or is the error in CentOS Stream distribution?
[14:59] <Guest12> pemensik[m] - that's exactly why I'm trying to figure out how to build it myself :')
[14:59] <meena> mine is built like this: https://codeberg.org/FreeBSD/freebsd-ports/src/branch/main/net/cloud-init-devel/Makefile
[15:00] <meena> when I bump the version, that's reflected there
[15:00] <Guest12> https://github.com/canonical/cloud-init/releases need at least `22.2` if I'm reading the release notes correctly
[15:00] <minimal> pemensik[m]: check /var/log/cloud-init.log to see which renderer(s) are being used for CentOS?
[15:01] <pemensik[m]> I don't understand cloud-init enough to know where to look.
[15:01] <minimal> pemensik[m]: I just told you the filename
[15:01] <pemensik[m]> https://src.fedoraproject.org/rpms/cloud-init might provide recent SRPM buildable on centos 9
[15:02] <pemensik[m]>  Selected renderer 'sysconfig' from priority list: None
[15:03] <minimal> so then cloud-init isn't/shouldn't be creating/modifying /etc/network/interfaces as that is done by the "eni" renderer
[15: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 anymore
[15:05] <minimal> for Network Manager configuration then "network-manager" renderer should be used
[15:05] <pemensik[m]> is there way to recreate only network configuration from cloud-init, but leave ssh keys configured?
[15:06] <minimal> which 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.noarch
[15:07] <pemensik[m]> server ssh keys, as shown in /var/log/cloud-init-output.log ?
[15:10] <minimal> I assume you could set "ssh_deletekeys: false" in your user-data, clean up cloud-init and re-run it
[15:13] <minimal> looking 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, networkd
[15:16] <pemensik[m]> just cleaned all anyway, but thanks. Will try next time
[15:17] <minimal> pemensik[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 differently
[15:23] <pemensik[m]> minimal: do you know how it chooses which renderer to use? where is that specified?
[15:24] <minimal> but it can be potentially overridden in other places (i.e. files in /etc/cloud/cloud.cfg.d/ directory)
[15:25] <minimal> oops, /etc/cloud/cloud.cfg
[15:26] <minimal> are you using a standard CentOS image that comes with cloud-init or did you/someone else create this image?
[15:27] <pemensik[m]> found in  /etc/cloud/cloud.cfg.rpmnew:      renderers: ['sysconfig', 'eni', 'netplan', 'network-manager', 'networkd' ]
[15:28] <pemensik[m]> original /etc/cloud/cloud.cfg does not contain renderers at all
[15:29] <pemensik[m]> I did not create anything, but the machine were created by my colleague. I have no direct access into Digital Ocean interface
[15:29] <pemensik[m]> I believe it should be stock CentOS
[15:30] <minimal> ok, 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, sorry
[15:30] <minimal> as whomever created the image I'd expect to ensure it is configured appropriately
[15:31] <pemensik[m]> well it works and boots even this way. Not everyone wants ipv6 connectivity in their machines
[15:31] <minimal> sorry? I didn't mention IPv6
[15:32] <minimal> so it is working? so what is the actual problem then?
[16:07] <pemensik[m]> at least from our internal openstack machines, centos 9 still chooses Selected renderer 'sysconfig' for some reason. 
[16:11] <minimal> right, because by default cloud-init uses a cloud.cfg for CentOS that has sysconfig specified as the 1st renderer to try and use
[17:57] <bahamat> Is there a way I can force detection of the datasource without doing any of the other stuff?
[17:57] <bahamat> I.e., I just want to have cloud-init tell me what it thinks the data source is.
[18:00] <falcojr> bahamat: /usr/lib/cloud-init/ds-identify --force, then check /run/cloud-init/cloud.cfg or /run/cloud-init/ds-identify.log
[18:00] <falcojr> path 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 way
[18:01] <bahamat> falcojr: Thanks.
[18:06] <meena> new release broke SmartOS datasource
[18:13] <bahamat> meena: Yeah, I reported that bug. That's why I'm here.
[20:05] <ananke> I 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 works
[20:28] <meena> ananke: what are the errors?
[20:34] <ananke> The error is cloud-init: TypeError: a2b_base64() argument 1 must be string or buffer, not None
[20:35] <meena> and what does the trace look like? and the cloud-config?
[20:38] <ananke> it'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/XrQPy
[20:39] <ananke> and the result is https://dpaste.org/tBs7q
[20:40] <ananke> base64 encoding is done on macos with base64 < inputfile. point being, there is actual value provided to the 'content: ' param
[20:41] <ananke> what's interesting is that:
[20:42] <ananke> 1) if the file with base64 encoding is first, then cloud-init throws that error
[20:43] <ananke> 2) if the file with base64 encoding is second, then cloud-init throws no errors, but it creates only the first file
[20:44] <ananke> and if I run the 'sudo cloud-init clean --logs ; sudo cloud-init init --local
[20:44] <ananke> and if I run the 'sudo cloud-init clean --logs ; sudo cloud-init init --local ; sudo cloud-init init
[20:44] <ananke> the base64 file will be created
[20:46] <ananke> baffles 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 ID
[20:47] <ananke> hah. and it works now. it's one of those days, do something for N number of times, and somehow it fixes itself
[21:15] <meena> weird 
[21:17] <minimal> ananke: 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:20] <minimal> perhaps AWS have updated their AL2023 images now with that fix
[21:20] <meena> ah
[21:20]  * meena is not paying enough attention