[04:09] may be able to work on that gentoo stuff [04:09] finally [04:10] however, before I can switch my images from glean to cloud-init I need to figure out why I need to reboot the server to get networking working [04:10] because that's a thing [04:12] on first boot it doesn't find the networking config, second boot it doe [04:12] on first boot it doesn't find the networking config, second boot it does [04:21] uses the same data source both times [04:21] https://gist.github.com/prometheanfire/e7fe7d6b70ebcb8710ef6dfc1a681112 [04:45] smoser: looks like anything using the old network backend won't bring up the interfaces automatically [04:46] in distros/__init__.py apply_network_config is run with bring_up=false [04:46] this calls the old backend with that false value [04:46] the old backend defaulted to true [04:52] smoser: I'm confused why you changed the default to false here 9c0a2abc8d2c0e390745ddb163f5eae07b20d61d [04:53] smoser: the default is true everywhere else === cpaelzer_ is now known as cpaelzer [05:38] apply_network_config was run with bring_up set to false [08:35] hello, i have installed cloud-init 0.7.5 on centos 7.2. i have a basic user-data file ready after reading the cloud-init examples (https://cloudinit.readthedocs.io/en/latest/topics/examples.html), but i don't know where to put the user-data file and how to force cloud-init to interpret the user-data file. can someone advise? === shardy is now known as shardy_lunch === shardy_lunch is now known as shardy === rangerpbzzzz is now known as rangerpb [13:01] prometheanfire, it runs with bringup = false because it should run before the OS goes to bring up networking. [13:01] so the OS then brings up the network as it would on normal boot. [13:14] smoser: on gentoo at least, for the first boot (when you add a service to startup automatically like is done) it needs to be brought up manually [13:14] /etc/init.d/net.eth0 start [13:14] etc [13:15] prometheanfire, hmm. [13:16] so during boot, you can't add new network configuration. [13:20] not within the same runlevel [13:21] if you configured in the boot runlevel it'd work iirc [13:21] do you change from 'boot' runlevel to another during normal boot ? [13:21] (ie, can we just put cloud-init in that boot runlevel ? thats basically what we do other places, and is kind of the intent) [13:22] yep [13:22] I can test with that [13:22] initially to me that sounds like the thing to do. [13:22] cloud-init and cloud-init-local should run "as early as possible" [13:23] let me make sure that's what I do with glean, but iirc that's how it was fixed [13:23] if that doesn't work, then we can change the caller to pass a flag other than bringup , or extend that one... saying that it is expecting the OS to bring this up. [13:24] yep [13:24] subprocess.call(['rc-update', 'add', 'glean', 'boot']) [13:24] I think it's diskimage-builder that needs updating for it, but I'll work on it [13:25] well can't the install somehow say that ? [13:26] this isn't debian where we instantiate services on install :P [13:26] cloud-init-local and cloud-init [13:26] its not instantiating the service on install. [13:26] can/should the others be moved to boot? [13:27] its saying when the service should run, or what services it should have. [13:27] config and final [13:27] well, for gentoo that's the same thing, given how service deps work [13:27] config later, final "rc.local like" [13:28] well, they have deps between then, so ordering isn'g a problem [13:33] /etc/init.d/cloud-init-local [13:33] that should be before netmount right? [13:34] I imagine so because it's a datasource for configuring the network [13:35] yes. [13:37] ok, I'll modify the package, think that is what is causing problems as well [13:54] oh, those are installed by cloud-init itself, https://git.launchpad.net/cloud-init/tree/sysvinit/gentoo [13:58] well, for now as a test I'll just sed that out === jgrimm is now known as jgrimm-out [15:42] smoser: well, not sure if this is the full fix, but it did start networking properly https://gist.github.com/prometheanfire/9d248da8e6f42fd29a51bc1aa3ece7e9 [15:42] \o/ [15:42] smoser: why is it trying to run that before net is set up? [15:43] well, 'init' should not run until after net is up [15:43] oh. [15:43] i confused you [15:43] i'm sorry [15:43] i was wrong [15:43] ah [15:43] that's fixable then [15:43] cloud-init local should run before net is up [15:43] and block net coming up [15:43] k, this is fixable :P [15:43] and cloud-init(-network) would then run *after* it is up [15:44] let me submit a pr [15:44] net generally comes up in the default run level [15:44] gists are pretty wonderful [15:44] does cloud-init lay down the config or or cloud-init-local [15:45] cldou-init-local will always render a networking configuration [15:45] cool [15:45] well, once per instance. [15:45] just being clear :D [15:45] i really need to write stage descriptions out better. [15:49] this is my diff [15:49] https://gist.github.com/cbf4a784c30156909809228f2cc1091f [15:49] and just cloud-init-local will be in the boot runlevel [15:50] cloud-init should actually be need net I think [15:52] actually, after is still better in this case [15:58] prometheanfire, is 'netmount' "configure the network" ? [15:58] or "mount network filesystems" [15:59] smoser: second one [15:59] but netmount needs net iirc [15:59] why not be more direct ? [15:59] before net [15:59] I am [15:59] you'll see [16:00] ok. [16:00] i was just reading that gist [16:00] :D [16:00] I changed since then [16:00] that was long long ago [16:00] now lets see if I can remember how to submit this [16:01] https://code.launchpad.net/~prometheanfire/cloud-init/+git/cloud-init/+merge/307969 [16:02] think that's right [16:16] Odd_Bloke, rharper cpaelzer i'm going to do something generally wrong.. [16:16] * rharper takes note [16:17] in order to get Odd_Bloke's fix into [16:17] yakkety [16:17] (systemd: Run cloud-init.service Before dbus.socket) [16:17] i'm going to re-order the last 3 commits [16:17] and re-write his changelog entry [16:17] so that the ubuntu upload has only his change [16:17] yeah [16:17] and has a sane commit message [16:17] just the single fix [16:18] FTR, I think my commit message is fine; people in the future will be less interested in "fixed something broken" than "here is why this line is here". But feel free to do whatever you want. :) [16:18] +1 on the general approach. === frickler_ is now known as frickler [16:20] smoser: let me know if any other info is needed on that pr [16:23] Odd_Bloke, yes, but the previous commit message described that well [16:23] so no need to duplicate that [16:23] Right, but wouldn't show up in blame. [16:23] http://paste.ubuntu.com/23289574/ [16:24] bah [16:24] dbus.service [16:24] smoser: dbus.service? [16:25] have you tested your chagen ? [16:26] By making that manual change a couple of days ago, yes. Let me test again now to confirm. [16:27] smoser: Confirmed. [16:27] smoser: I tested the dbus.socket in yakkety-daily instance on serverstack [16:28] smoser: in particular, if you check, systemctl list-dependencies dbus.service; you can see it depends on dbus.socket [16:28] and we'd like to ensure cloud-init runs before the dbus.socket is active [16:28] to ensure nss fails fast [16:28] ^ this [16:30] right. [16:34] deed is done. [16:34] pushed to master with re-worked history. [16:34] 109340b3c16857f526a75d4237d753b8cb82035e was pre-rework [16:38] https://git.launchpad.net/cloud-init/log/?h=ubuntu/devel now updated [16:43] building and uploading [16:45] uploaded http://paste.ubuntu.com/23289681/ [17:11] smoser: rewriting history is what winners do, so it can't be too bad === rtheis_ is now known as rtheis === natorious_ is now known as natorious [22:45] hey, cloud-final service module is failing, where can I obtain logs for that? [22:45] cloud-init-output.log is not showing anything [22:45] and journalctl -u cloud-final.service is sparse as well === rangerpb is now known as rangerpbzzzz [23:31] sather: /var/log/cloud-init.log ? [23:31] that's where I have it write to [23:31] doesn't even use a logging service and still writes there