| 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 | |
| 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/ ? | 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.git | 14:01 |
| meena | the SRPM should have the info on where it's getting the sources from | 14:07 |
| 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: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 |
| Guest12 | pemensik[m] - "Therefore only owners knows how it is built exactly." - not super helpful :') | 14:55 |
| minimal | portable? | 14:57 |
| 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:58 |
| 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 | 14:59 |
| 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:00 |
| 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:01 |
| pemensik[m] | Selected renderer 'sysconfig' from priority list: None | 15:02 |
| 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:03 |
| 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:05 |
| 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:06 |
| pemensik[m] | server ssh keys, as shown in /var/log/cloud-init-output.log ? | 15:07 |
| minimal | I assume you could set "ssh_deletekeys: false" in your user-data, clean up cloud-init and re-run it | 15:10 |
| 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:13 |
| pemensik[m] | just cleaned all anyway, but thanks. Will try next time | 15:16 |
| 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:17 |
| pemensik[m] | minimal: do you know how it chooses which renderer to use? where is that specified? | 15:23 |
| minimal | but it can be potentially overridden in other places (i.e. files in /etc/cloud/cloud.cfg.d/ directory) | 15:24 |
| minimal | oops, /etc/cloud/cloud.cfg | 15:25 |
| minimal | are 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 all | 15:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| minimal | so 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 |
| 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 | 16:11 |
| 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. | 17:57 |
| 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:00 |
| bahamat | falcojr: Thanks. | 18:01 |
| meena | new release broke SmartOS datasource | 18:06 |
| bahamat | meena: Yeah, I reported that bug. That's why I'm here. | 18:13 |
| 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:05 |
| meena | ananke: what are the errors? | 20:28 |
| ananke | The error is cloud-init: TypeError: a2b_base64() argument 1 must be string or buffer, not None | 20:34 |
| meena | and what does the trace look like? and the cloud-config? | 20:35 |
| 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:38 |
| ananke | and the result is https://dpaste.org/tBs7q | 20:39 |
| ananke | base64 encoding is done on macos with base64 < inputfile. point being, there is actual value provided to the 'content: ' param | 20:40 |
| ananke | what's interesting is that: | 20:41 |
| ananke | 1) if the file with base64 encoding is first, then cloud-init throws that error | 20:42 |
| ananke | 2) if the file with base64 encoding is second, then cloud-init throws no errors, but it creates only the first file | 20:43 |
| 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:44 |
| 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:46 |
| ananke | hah. and it works now. it's one of those days, do something for N number of times, and somehow it fixes itself | 20:47 |
| meena | weird | 21:15 |
| 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:17 | |
| minimal | perhaps AWS have updated their AL2023 images now with that fix | 21:20 |
| meena | ah | 21:20 |
| * meena is not paying enough attention | 21:20 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!