[01:22] <holmanb> ananke: and what triggers the shutdown? 
[01:24] <ananke> holmanb: aws ec2 shut down event, presumably comes in as an ACPI call. system performs regualr shutdown
[09:41] <aciba> community notice: cloud-init 23.4.3 is uploaded to ubuntu's -proposed pockets for SRU verification and review. We'll be performing our SRU validation of this release for stable Ubuntu releases over the next 7 days.  https://github.com/canonical/cloud-init/releases/tag/23.4.3
[15:33] <tryfan> Hi all, been having no luck figuring this out.  Is setting a DNS server on SLES/OpenSUSE Leap 15 supported in cloud-init?  It's setting the ip/gateway correctly in the ENI files but isn't touching the config file for netconfig, nor is it setting anything in resolv.conf.  I didn't see anything explicit in the code for setting the nameservers in suse
[15:33] <tryfan> either.
[17:50] <minimal> tryfan: what "ENI files"? AFAIK SLES/OpenSUSE have never used /etc/network/interfaces
[17:50] <minimal> where exactly are you specifying the DNS server to use? Which DataSource are you using?
[19:29] <tryfan> minimal: the datasource is NoCloud and is an ISO mounted to the VM on boot. The IP is being set in /etc/sysconfig/network/ifcfg-eth0 and gateway is in ifroute-eth0
[19:30] <minimal> ok, so wondering why you mentioned ENI
[19:32] <minimal> so did you check /var/log/cloud-init.log to see the network details cloud-init obtained from the ISO in order to config networking? can you pastebin (or equivalent) the user-data from the ISO?
[19:32] <tryfan> sorry, it looks so similar
[19:34] <tryfan> I'm getting the data again.  the relevant logs are: https://paste.centos.org/view/4e246ef2
[19:35] <tryfan> if I set resolv_conf in the cloud.cfg, cloud-init sets resolv.conf but it's overwritten by wicked/netconfig on reboot
[19:35] <minimal> so where do you want/expect the nameserver to be set?
[19:40] <tryfan> if could-init is to obey whatever the official sles way is, it would be according to this: https://documentation.suse.com/sles/15-SP5/html/SLES-all/cha-network.html#sec-network-yast-change-host
[19:41] <tryfan> so either a command to yast, or modifying the /etc/sysconfig/network/config file
[19:41] <tryfan> the more I dig, the more I dislike the way suse does things
[19:44] <tryfan> I saw an old bug around this, but nothing was done with it: https://bugs.launchpad.net/cloud-init/+bug/1849296
[19:44] -ubottu:#cloud-init- Launchpad bug 1849296 in cloud-init "use netconfig for DNS settings on SUSE" [Medium, Expired]
[20:21] <minimal> tryfan: the comments in that bug did say "if we work with netconfig and support a "merging" behaviour that would be behaviour change for which we will probably also get complaints"
[20:34] <tryfan> minimal: imho, doing nothing will eventually get a complaint.  as it stands, it just doesn't work and there's no option to just clobber resolv.conf support in suse, which I'd personally be ok with.  at least there would be an option to make it work
[20:35] <tryfan> right now, there's just nothing
[20:44] <minimal> "clobber resolv.conf support" support? how about not providing "manage_resolv_conf: true" and also provide "nameservers" (within "resolv_conf:") in your user-data?
[20:44] <minimal> s/not //
[20:53] <tryfan> minimal: I did: https://paste.centos.org/view/ea1e333b
[21:01] <minimal> umm, why are you specifying network config in BOTH meta-data and network-config files? why are you specifying DNS config in meta-data and network-config and user-data?
[21:05] <tryfan> it's a payload for multiple OSes and versions, it works for everything from centos 7 to ubuntu 22
[21:10] <minimal> very weird
[21:10] <tryfan> I understand it's not ideal and in a perfect scenario, it would be precise for every distro and version target, but it's not exactly the space I'm in
[21:14] <minimal> well it will be hard for someone (else) to figure out any interactions between duplicated settings in different places..
[21:25] <tryfan> in the logs I posted starting line 8 it has the correct config, sets IP, gateway, and that's it.  no mention of dns or resolvers anywhere else.  I don't believe it's an interaction issue.
[21:25] <tryfan> I understand it's not cut and dried, I even see other attempts to make it work such as https://github.com/canonical/cloud-init/issues/3606
[21:25] -ubottu:#cloud-init- Issue 3606 in canonical/cloud-init "[cloud-init] '/etc/resolv.conf' is out of control of netconfig after done cloud-init GOSC on SLES15SP1" [Open]
[21:26] <tryfan> I'm going to try disabling all control of that file from sles and see if I can get it to work
[21:31] <minimal> tryfan: if you're aware of problematic multi OS differences in cloud-init behaviour it would be useful to raise Issues for them as I assume many/most cloud-init users only use it with 1 or 2 different distros....if such issues aren't highlighted then they'll probably never get addressed
[21:31] <minimal> obviously multiple cloud-init versions (especially older ones shipped by more "enterprise", i.e. slow to update, distros) complicates things
[21:33] <minimal> the cloud-init.log portion you provided doesn't show the activation of any modules (such as the resolv_conf one)