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:55 |
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:56 |
Japje | systemctl show cloud-config, cloud-final and cloud-init-local services as enabled | 09:57 |
Japje | the image i used is the latest debian10 openstack iamge | 10:04 |
Japje | image* | 10:04 |
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? | 10: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 | 11:41 |
Odd_Bloke | Japje: Glad you tracked it down! Is there anything else we can help with? | 13:09 |
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:10 |
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:11 |
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:13 |
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:14 |
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:15 |
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:17 |
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:20 |
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:21 |
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:22 |
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:30 |
Odd_Bloke | Hold on, just launching a Debian instance so I can check if my assumptions are Ubuntu-specific before I respond. :) | 13:40 |
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:44 |
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:45 |
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:48 |
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:49 |
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:50 |
Odd_Bloke | Would you be able to pastebin your network_data.json? | 13:51 |
mrtmr | btw my debian image is created with disk-image-builder and my network_data.json is rendered by bifrost | 13:52 |
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:54 |
mrtmr | https://gist.github.com/mrtmrcbr/505e335f464203707a367666d1bfccd1 | 13:56 |
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:57 |
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? | 13:58 |
mrtmr | i did some changes should i send this logs with clean instalation | 14:03 |
Odd_Bloke | Ideally, yes, please. | 14:12 |
mrtmr | Odd_Bloke '''cloud-init collect-logs''' this command, which release does come with | 14:30 |
Odd_Bloke | mrtmr: Ah, that's a question I should have asked earlier: what version of cloud-init are you using? | 14:34 |
mrtmr | my debian image came with cloud-init 0.7.9 by default. disk-image-builder puts it there | 14:36 |
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:41 |
Odd_Bloke | mrtmr: Are you able to try Debian stable (which has 18.3) and see if you get different behaviour? | 14:48 |
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:49 |
rharper | Odd_Bloke: it is root owned, but why can sshd read user's '7' but not roots? | 14:54 |
Odd_Bloke | Does it drop permissions down to the SSH'ing user or something? | 14:59 |
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:03 |
Odd_Bloke | OK, we'll see if that works; I was suggesting using a Debian stable image, FWIW. | 15:13 |
mrtmr | Odd_Bloke after reboot resolv.conf didnt change | 15:24 |
Odd_Bloke | rharper: I'm now +1 on tribaal's Exoscale change; shall I mark it Approved to land it? | 16:20 |
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:21 |
tribaal | will pass the thanks forward | 16:23 |
rharper | Odd_Bloke: +1 | 16:29 |
Odd_Bloke | tribaal: Approved, should be auto-landed Real Soon Now. :) | 16:35 |
tribaal | Odd_Bloke: rharper: nice! Thanks a lot! | 17:09 |
tribaal | blackboxsw: smoser: thanks a lot to you both as well! | 17:12 |
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:52 |
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 | 17:54 |
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:13 |
AnhVoMSFT | thanks blackboxsw | 18:15 |
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:17 |
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:19 |
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:20 |
AnhVoMSFT | oh there was a semicolon at the end | 18:21 |
AnhVoMSFT | it shows for me now | 18:21 |
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:22 |
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:25 |
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:26 |
rharper | AnhVoMSFT: oh trailing semi-colon | 18:46 |
rharper | sorry | 18:46 |
rharper | http://hoardedhomelyhints.dietbuddha.com/2014/02/python-aggregating-multiple-context.html | 18:46 |
Odd_Bloke | You can nest context managers: with A(): with B(): thing | 19:01 |
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:38 |
blackboxsw | reading now | 20:52 |
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:13 |
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:15 |
blackboxsw | good to have the method API defined up in the base DataSource to guide future implementation | 21:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!