=== Beret- is now known as Beret [10:55] Hello, I am using cloud init to create an ext4 filesystem on an encrypted LUKS device and then mount it. Documentation for LUKS suggests that every block should be written to prior to filesystem creation. I think that `mkfs.ext4 -cc /path/to/device` will do this but cant find an option for this kind of thing in the documentation. Any suggestions? [13:56] mjh: hm... i dont think you can really manage taht with cloud-init at the moment. [13:57] you could probably use something in a boothook or bootcmd [13:57] bootcmd: [13:57] - [dd, if=/dev/zero, of=/path/to/device] [14:10] I havent looked at boothooks / bootcmds yet. I shall RTFM :-) [15:21] smoser: sorry about that license agreement, apparently i put the wrong email, i just responded to the person trying to verify me on the agreement to put the correct one [15:22] hopefully it should be good to go in a bit [15:24] gtmanfred: great thanks. your word here is good enough. it does take a bit for a human to process. [15:24] :+1: [15:25] can you reply in that mp ? [15:25] (even t hough i just said your word here was good enough :) [15:25] yup, one second [15:26] done [15:26] i think [15:26] i can respond to launch pad emails and they post them right? [15:26] meh, commenteed [15:26] yes. [15:27] i did both just to be certain :) [15:41] cool, thanks! === blackboxsw changed the topic of #cloud-init to: Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting: Monday 3/5 16:00 UTC | cloud-init 18.1 released (Feb 22, 2018) === shardy is now known as shardy_afk [18:18] Hi, I'm using cloud-init on an openstack guest and have a need for static network configuration. I can see in my cloud-init.log file that the network_data.json file was successfully requested from the metadata service and the code I've reviewed in the openstack helper seems like it should be generating a static config for ipv6 but the default interfaces file with dhcp4 is the only thing written. [18:18] Can I force cloud-init to reconfigure networks? [18:19] redkrieg: can you share your network_data.json and what your final network config is ? [18:20] redkrieg: Also, if you want cloud-init to configure networking in Openstack, you need to specify configdrive at this time ; [18:20] it's on the roadmap to read network config from the metadata service early enough that cloud-init can write out a network configuration like it does with configdrive, but that's not done yet [18:21] the json comes out like this: https://pastebin.com/E9uJZRBn [18:21] I didn't realize that wasn't implemented. The docs seem to indicate that it is supported :( [18:22] https://pastebin.com/ivRtvyJ4 is the config that it generates, but that makes sense if metadata isn't acquired early enough. [18:23] how about forcing cloud-init to rebuild network config? is that something that can be done? it doesn't appear to be a module that I can find. [18:23] if you change the instnace to use configdrive, it will work [18:23] yeah. [18:23] well, after networking is up, trying to re-apply could interrupt existing connections [18:24] not worried about that, it'd be something a client would do from our custom control panel and will come with all the usual warnings about what modifying network configs does [18:26] redkrieg: we do want to make this do the right thing. [18:26] and its not really a difficult change for first boot configuration [18:26] (hotplug is more difficult) [18:26] just a matter of resources at the moment. [18:27] yeah, once the user gets their hands on something they tend to create edge cases :D [18:28] * smoser shakes fist at users === logan_ is now known as logan- [19:01] config drive is working great for initial boot, thanks! Is it possible to force cloud-init to reconfigure networking on the next boot or something similar? [19:06] redkrieg: no. not really. [19:08] ouch. guess I'll have to cook something up to runcmd on boot and do it manually :\ [19:10] I think a neat feature would be testing for the absence of /etc/network/interfaces.d/50-cloud-init.cfg (or related files for other distros) and rebuilding. Might take a swing at that over the weekend. [20:22] smoser: powersj: so both chrony and timesyncd happily don't run in containers unless you run them with the right capabilities to adjust time; isc-ntp seems to run anyhow even if it can't adjust the time [20:22] that does make the integration test a bit more challenging w.r.t asking the client itself how it's configured (versus just parsing the config file) [20:22] thoughts ? [20:32] what are the right capabilities? [20:35] heh, !Container [20:35] which is annoying [20:36] lemme get the chrony one [20:37] ConditionCapability=CAP_SYS_TIME was not met [20:38] timesyncd probably should use the ConditionCapability check that chrony uses but that's an upstream change [20:40] ha [20:41] rharper: so if someone tries to setup time via chrony with cloud-init with a container what is the expected behavior? nothing? warning message? [20:42] from cloud-init perspect, we did what we were asked [20:42] chrony service it self can't start for it's one restrictions [20:42] I mean, it's not really any different than ntpd, which runs but cannot adjust the clock without capabilities [20:43] chrony has a track time but don't adjust the system time mode; however, in unpriv container, it still wants to drop root privs, but that's a restricted capability so it can't do that [20:43] then for the test validate the config and move on? [20:43] well, do we do different tests on kvm vs lxd ? [20:44] I need to run in a vm and see if I can get them to dump out any information anyhow [20:44] systemd packages are notorious for not saying anything about their config [20:44] the timedatectl --status shows NTP Sync=Yes [20:44] that's it [20:44] thanks [20:45] and we do not run different tests for kvm vs lxd [20:47] well, crud [20:53] rharper: I have an example started [20:54] for the snap testing [20:54] as snap on container requires squashfuse [20:54] and non-container doesn't [20:54] our cloud_tests need to provide that platform information to the individual unit tests [20:54] well, the thing is, I'm not really ok running priv container trying to sync time [20:55] I think we need a way to skip tests on certain platforms [20:55] if that's not there [20:56] so, we'll collect the data, then run the verify on it; if it knows that it was collected on a particular platform we could raise SkipTest where we know it won't be accurate [21:04] rharper: it's not, but I agree we do need a skiptest decorator that chan check platform details [21:08] well [21:08] guess who get's to poke at that [21:08] but not in the initial branch [21:08] * rharper is going to push that up for review shortly [21:24] rharper: i think that cloud-init does what it was told [21:25] yeah [21:25] if that means installing a servie that will fail to start [21:25] then we still did what we were told [21:25] I agree; I'm mostly concerned about trying to verify if our template is correct [21:25] its kind of over-zealous to have a service that simply says "i dont run in a container" [21:25] we had that ntp bug about not having config on disk prior to install and restarting the daemon; we do those things now [21:25] but our template could still be broken [21:26] baking in assumption that the system clock is not namespaced [21:26] smoser: yes, systemd is obnoxious =) [21:26] or the container platform doesnt provide some psuedo mechanism for that. [21:26] a day hasn't gone by where i"m not swearing at something packaged in systemd, so no change there [21:27] I suspect we didn't add an integration test for UbuntuCore which used the timesyncd path, or we'd see this (ie, we configure it, but have no way of verifying it uses the servers) since timedatectl doesn't emit useful information other than 'ntp sync=Yes' if it's synced [21:28] I do think we can run this in KVM and at least for some clients (ntp, at least, possibly chrony) as the daemon for what servers it connected with ; and validate that matches what we configured ; I'll play with chrony in a VM [21:33] systemd is love. [21:33] said no one ever [21:33] :-) [21:33] until *now* [21:34] Still amazed at how quickly it got pushed through. [21:35] But I just try to hold my nose and focus on other things. :-) [21:35] * blkadder eagerly awaits the LinuxRegistry [21:36] rharper: do you remember the bug where cloud-init was hanging tdue to /dev/random / kernel-config missing some options ? [21:36] can't find it [21:36] cyphermox i think you filed ? [21:36] smoser: yes [21:37] https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1727358 [21:37] Ubuntu bug 1727358 in python3.6 (Ubuntu) "cloud-init is slow to complete init on minimized images" [Wishlist,Triaged] [21:37] smoser: lol, I know where you're going [21:40] rharper: blkadder: I ordered this shirt for you both: https://goo.gl/hzFdR3 [21:40] HAHAHA [21:40] (╯°□°）╯︵ ┻━┻ [21:40] dpb1: just you wait dpb1 [21:41] Is there an option to order one bathed in tears? [21:43] I think they come with a first aid kit for all the fights you will get in after putting it on. [23:05] nerd fights, I think there is an ESPN channel with that kinda action [23:07] hrm one last manual test for ubuntu SRU https://pad.lv/#1731868 [23:07] or rather bug #1731868 [23:07] bug 1731868 in cloud-init (Ubuntu) "cloud-id: enable ESXi 6.5.0" [High,Fix released] https://launchpad.net/bugs/1731868 [23:08] I can upgrade my vphere bootstrapped env w/ latest cloud-init and the ds-identify warning is gone... but not sure if there is an easier test for that.