[04:19] <energizer> When i start up there's a long period of waiting for network connection that it doesnt find -- how can i disable this?
[04:19] <energizer> or how can i disable cloud-init altogether?
=== shardy_afk is now known as shardy
=== shardy is now known as shardy_afk
=== shardy_afk is now known as shardy
=== shardy is now known as shardy_afk
[15:34] <rharper> blackboxsw: https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/329122  (logging-gmtime)
[15:35] <blackboxsw> grabbing it
[15:36] <rharper> I think that should force the analyze code which parses timestamp strings to produce UTC based timestamp values
[15:37] <rharper> it's possible that in the unittest if analyze/dump.py isn't pulling in logging from cloudinit/log.py then we'd miss it
[15:37] <rharper> but I think in general, we want any cloud-init module to import logging via cloudinit.log
=== shardy_afk is now known as shardy
[17:06] <blackboxsw> rharper: ok reviewed https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/329122 it'd be nice to have a unit test for that. but doesn't have to block this one.
[17:13] <blackboxsw> also I pushed latest/final changes for the timestamp work in unit tests on the analyze branch.  I didn't have to mock, but let the unit test calculate timestamps using local time as well. https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/328819
[17:31] <rharper> blackboxsw: cool
[17:31] <rharper> I'll re-review
[18:57] <blackboxsw> just sent and email to Sankar about the vmware branch that's in activereview (too see if we might get that landed before next week too.
[19:32] <rharper> powersj: I see you performed the subprocess.Popen dance to get your file via stdin, nice !
[19:32] <powersj> rharper: thx!
[19:32] <powersj> that worked really easily
[19:33] <rharper> we could look at adding stdin support to subp
[19:33] <rharper> since w're setting the values via Popen anyhow; just not there today
[23:23] <stanguturi> Need some help regarding the 'network config rendering'... I have a datasource that specifies all the proper network configuration in proper format in network_config property. I noticed that cloud-init writes that settings to /etc/network/interfaces.d/50-cloud..cfg file instead of /etc/network/interfaces
[23:23] <stanguturi> Any specific reason for this.
[23:28] <nacc> stanguturi: presumably so that it's easy to know what cloud-init owns?
[23:28] <nacc> stanguturi: does it break something?
[23:28] <nacc> (also actually with two . ?)
[23:29] <stanguturi> @nacc, Not actually breaks. I want to know how does the system work if we write the network configuration data in a file other than /etc/network/interfaces
[23:30] <nacc> stanguturi: does your /e/n/i have a line like "source-directory interfaces.d" ?
[23:30] <nacc> stanguturi: i believe that is the default in debian, not sure, don't have a fresh image sitting in front of me at the moment
[23:34] <stanguturi> I don't think I have it. Will check Thanks
[23:34] <nacc> stanguturi: just going off of `man interfaces`