[09:55] <Japje> hey guys, im trying to get debian10 into maas as an image (which i've got working). However for some reason even though the cloud-init is enabled it will not run on first boot for some reason
[09:55] <Japje> as soon as i manually run cloud-init init --local i can restart the network to get it going
[09:56] <Japje> (the interfaced.d/50-cloud-init.cfg file isnt created therefor no network)
[09:56] <Japje> anyone perhaps an idea what could be preventing it from running on boot?
[09:57] <Japje> systemctl show cloud-config, cloud-final and cloud-init-local services as enabled
[10:04] <Japje> the image i used is the latest debian10 openstack iamge
[10:04] <Japje> image*
[10:41] <Japje> hmnz, cloud-init status says disabled, but i have neither a /etc/cloud/cloud-init.disabled nor a commandline in /proc/cmdline that would cause that
[10:41] <Japje> any other ways to have it disabled?
[11:41] <Japje> it seems that cloud-init gets disabled when there are no datasources, and it looks like maas throws away the only datasource there is, so i guess i found the cause
[13:09] <Odd_Bloke> Japje: Glad you tracked it down!  Is there anything else we can help with?
[13:10] <Japje> neah, i guess im mostly fighting maas for trying to run debian in it
[13:10] <Japje> nothing thats cloud-inits fault
[13:10] <Odd_Bloke> Japje: It's cool that you're trying to get that to work!
[13:11] <Japje> its booting and the network comes up
[13:11] <Japje> but none of the user_data i push on deploy actually gets in the vm
[13:13] <Odd_Bloke> It looks like there is a #maas on Freenode, have you tried asking for help in there?  I believe https://discourse.maas.io also gets pretty frequent use, so that might be another good forum to seek assistance?
[13:14] <Japje> yeah im on the irc channel
[13:14] <Japje> but irc is very quiet lately
[13:14] <Japje> so i might check out their discord
[13:15] <mrtmr> Hi everyone, in openstack/bifrost we can pass network_data.json file to server for cloud-init with configdrive. Today I tried to pass a user_data file and I succeed it, with biforst-configdrive-dynamic role. but there is a problem with cloud.cfg file I must to add resolv_conf module to in it otherwise my user_data is not working  at boot time. in m
[13:15] <mrtmr> y user data there is a basic expamle for configure /etc/resolv.conf file do you have any idea how to i re-write cloud.cfg file
[13:17] <Odd_Bloke> mrtmr: o/  What distro are you using?
[13:17] <mrtmr> in my default cloud.cfg file, there is not inside resolv_conf module
[13:17] <mrtmr> debian 9 it created with disk image builder by bifrost
[13:20] <mrtmr> if I add this module name by my hand to cloud.cfg and re-run again it execute that module
[13:20] <Odd_Bloke> Yep, the default Debian cloud.cfg won't include cc_resolv_conf.
[13:21] <Odd_Bloke> Looking at the documentation for that module (https://cloudinit.readthedocs.io/en/latest/topics/modules.html#resolv-conf) suggests it's only supported for Fedora, RHEL, and SLES.
[13:22] <Odd_Bloke> It also says: "And, in Ubuntu/Debian it is recommended that DNS be configured via the standard /etc/network/interfaces configuration file."
[13:22] <mrtmr> okey my bad sry missed that part of it
[13:22] <Odd_Bloke> Not a problem!
[13:22] <Odd_Bloke> What is it that you're doing that leads you to want cc_resolv_conf to run?
[13:30] <mrtmr> cloud-init is configure my interfaces but it is not edit my resolv.conf file
[13:30] <mrtmr> even my network interfaces up and running
[13:40] <Odd_Bloke> Hold on, just launching a Debian instance so I can check if my assumptions are Ubuntu-specific before I respond. :)
[13:44] <Odd_Bloke> mrtmr: OK, so if you're passing network configuration, I think I would expect the network configuration backend to configure DNS appropriately.
[13:45] <Odd_Bloke> Which I think should mean that you don't need the cc_resolv_conf module to do it for you.
[13:45] <Odd_Bloke> Note the "I think"s in there, though. ;)
[13:48] <mrtmr> is there a way to add cc_resolv_conf module to cloud.cfg
[13:48] <Odd_Bloke> mrtmr: Well, yes, you can just edit the file, or drop in a cloud.cfg.d snippet.
[13:48] <Odd_Bloke> mrtmr: Note that you need to replicate the entire list in a drop-in, though.
[13:49] <Odd_Bloke> Otherwise you'll _only_ run cc_resolv_conf.
[13:49] <Odd_Bloke> mrtmr: But I don't think you should need cc_resolv_conf to run if you're specifying network_data.json.
[13:50] <Odd_Bloke> (So it may be better to dig in to why you aren't getting the configuration you want from the network rendering.)
[13:50] <mrtmr> yeah im specifying network_data.json
[13:51] <Odd_Bloke> Would you be able to pastebin your network_data.json?
[13:52] <mrtmr> btw my debian image is created with disk-image-builder and my network_data.json is rendered by bifrost
[13:54] <Odd_Bloke> mrtmr: Right, I'm trying to work out if my assumptions about what your cloud is doing are correct; there are a lot of ways to deploy/configure OpenStack. :p
[13:56] <mrtmr> https://gist.github.com/mrtmrcbr/505e335f464203707a367666d1bfccd1
[13:57] <mrtmr> here is my network_data.json
[13:57] <Odd_Bloke> OK, I would expect to see 195.226.196.87 configured as your DNS server without cc_resolv_conf; does that not match what you're seeing?
[13:58] <Odd_Bloke> And, if it doesn't, could you file a bug (https://bugs.launchpad.net/cloud-init/+filebug) with the output of `cloud-init collect-logs` from a failing instance so we can dig in to what is going on?
[14:03] <mrtmr> i did some changes should i send this logs with clean instalation
[14:12] <Odd_Bloke> Ideally, yes, please.
[14:30] <mrtmr> Odd_Bloke '''cloud-init collect-logs''' this command, which release does come with
[14:34] <Odd_Bloke> mrtmr: Ah, that's a question I should have asked earlier: what version of cloud-init are you using?
[14:36] <mrtmr> my debian image came with cloud-init 0.7.9 by default. disk-image-builder puts it there
[14:41] <Odd_Bloke> OK, 0.7.9 is pretty old at this point, which would explain why the network config isn't being consumed properly.
[14:41] <Odd_Bloke> blackboxsw: rharper: https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/371090 <-- small MP to make doc builds not hang randomly due to an external dependency
[14:48] <Odd_Bloke> mrtmr: Are you able to try Debian stable (which has 18.3) and see if you get different behaviour?
[14:49] <mrtmr> yeah it is dissapointing, in debian repos there is not avaliable new releases
[14:49] <Odd_Bloke> rharper: https://bugs.launchpad.net/bugs/1839061 <-- presumably /etc/ssh/... is root owned, not user owned, so the "7" applies to a different person?
[14:49] <ubot5> Ubuntu bug 1839061 in cloud-init "Wrong access permissions of authorized keys directory when using root-owned location" [Medium,Triaged]
[14:49] <Odd_Bloke> mrtmr: Debian does have 18.3, which is ~17 months newer than 0.7.9, at least.
[14:54] <rharper> Odd_Bloke: it is root owned, but why can sshd read user's '7' but not roots?
[14:59] <Odd_Bloke> Does it drop permissions down to the SSH'ing user or something?
[15:03] <mrtmr> okey it is avaliable from debian strecht repo but i installed with deb file and i rebooted the machine
[15:03] <mrtmr> sry - it is not avaliable*
[15:13] <Odd_Bloke> OK, we'll see if that works; I was suggesting using a Debian stable image, FWIW.
[15:24] <mrtmr> Odd_Bloke after reboot resolv.conf didnt change
[16:20] <Odd_Bloke> rharper: I'm now +1 on tribaal's Exoscale change; shall I mark it Approved to land it?
[16:21] <tribaal> \o/
[16:21] <tribaal> thanks Odd_Bloke
[16:21] <Odd_Bloke> rharper: Or, rather, I'm going to mark it Approved unless you have objections. :)
[16:21] <Odd_Bloke> tribaal: Thank you, and thanks to Mathieu too!
[16:23] <tribaal> will pass the thanks forward
[16:29] <rharper> Odd_Bloke: +1
[16:35] <Odd_Bloke> tribaal: Approved, should be auto-landed Real Soon Now. :)
[17:09] <tribaal> Odd_Bloke: rharper: nice! Thanks a lot!
[17:12] <tribaal> blackboxsw: smoser: thanks a lot to you both as well!
[17:52] <AnhVoMSFT> rharper - any idea how I can wrap an events reporting context manager around this         with EphemeralDHCPv4(fallback_nic):
[17:52] <AnhVoMSFT> we want to use the event context manager around the dhcp's lease obtain, which is a context manager itself
[17:54] <AnhVoMSFT> I can create our own context manager and in the __enter__ I can probably call the enter method of EphemeralDHCPv4 and wrap it within the event's reporting context mgr, but want to check if you can think of a better way
[18:13] <blackboxsw>  AnhVoMSFT I'll peek at that to see what would work. I think we have a second example of that (calling the __enter__ directly within a different context mgr)
[18:15] <AnhVoMSFT> thanks blackboxsw
[18:17] <blackboxsw> also AnhVoMSFT I'll send you an email. looking at how best to create a separate subnet on separate nic in Azure that has it's own separate gateway. Mostly to validate this branch behavior: https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/370970
[18:17] <blackboxsw> I couldn't find an easy way in Azure portal to create a separate subnet w/ a unique gateway. Not really sure that that's a frequent use-case on Azure
[18:17] <AnhVoMSFT> Sure blackboxsw - if I don't know how I can go find the answer
[18:19] <rharper> AnhVoMSFT: http://hoardedhomelyhints.dietbuddha.com/2014/02/python-aggregating-multiple-context.html; the ExitStack in the comments here looks like what we want,
[18:20] <AnhVoMSFT> strange, that link gave me "Sorry, the page you were looking for in this blog does not exist."
[18:20] <blackboxsw> AnhVoMSFT: no worries thought I'd ping in case. it's slightly related to the multi-ip support on the primary nic in Azure
[18:20] <blackboxsw> hrm shows for me
[18:20] <blackboxsw> til multi-context mgr
[18:20] <blackboxsw> from the blog:
[18:20] <blackboxsw> with contextmanager1, contextmanager2, contextmanager3, contextmanager4:
[18:20] <blackboxsw>     pass
[18:21] <AnhVoMSFT> oh there was a semicolon at the end
[18:21] <AnhVoMSFT> it shows for me now
[18:22] <AnhVoMSFT> thanks , I will look into it closely
[18:22] <AnhVoMSFT> it might not work for us though, as I only want to capture the time of obtaining dhcp, (__enter__ call of EphemeralDhcp), not the E2E time of the whole block
[18:25] <blackboxsw> AnhVoMSFT: also, EphemeralDHCPv4 context manager is doing the same kind of nesting you suggested in obtain_lease/clean_network method using EphemeralIPv4Network.__enter__()
[18:26] <blackboxsw> to it manages direct calls EphemeralIPv4Network.__enter__ && __exit__ when needed
[18:26] <AnhVoMSFT> yeah I looked into that yesterday, but I was hoping that I am missing some cool trick of Python :)
[18:26] <AnhVoMSFT> I think I'll go with that mechanism of calling the __enter__ method
[18:46] <rharper> AnhVoMSFT: oh trailing semi-colon
[18:46] <rharper> sorry
[18:46] <rharper> http://hoardedhomelyhints.dietbuddha.com/2014/02/python-aggregating-multiple-context.html
[19:01] <Odd_Bloke> You can nest context managers: with A(): with B(): thing
[20:38] <Odd_Bloke> rharper: blackboxsw: Do either of you have strong feelings about the default behaviour of host key publication?  It's a no-op on data sources that don't support it, so I think it's fine to keep it that way until we have a data source which introduces support but _doesn't_ want it to be the default.  What do you think?
[20:38] <Odd_Bloke> (This is in reference to https://code.launchpad.net/~wrigri/cloud-init/+git/cloud-init/+merge/370348)
[20:52] <blackboxsw> reading now
[21:13] <rharper> Odd_Bloke: yeah; because I think it's a really great feature and something that DataSources should want to do; I'm generally in favor of enabling by default;
[21:15] <blackboxsw> sorry I relooked at AWS instance connect functionality to see if it was comparable. ok so they want a callback to publish host keys  to their backplane for security of connecting services to their spawned vms. I was wondering if this was like AWS instance connect functionality (not in cloud-init) but I think instance connect for was was the other way around (backplane publishing backend service keys to the host).   It
[21:15] <blackboxsw> seems unique to GCE for the moment, and a noop is a good enough placeholder for the future.
[21:16] <blackboxsw> good to have the method API defined up in the base DataSource to guide future implementation