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