| 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? | 04:19 |
| === 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 | ||
| rharper | blackboxsw: https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/329122 (logging-gmtime) | 15:34 |
| blackboxsw | grabbing it | 15:35 |
| rharper | I think that should force the analyze code which parses timestamp strings to produce UTC based timestamp values | 15:36 |
| 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 | 15:37 |
| === shardy_afk is now known as shardy | ||
| 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:06 |
| 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:13 |
| rharper | blackboxsw: cool | 17:31 |
| rharper | I'll re-review | 17:31 |
| 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. | 18:57 |
| 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:32 |
| 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 | 19:33 |
| 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:23 |
| 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:28 |
| 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:29 |
| 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:30 |
| stanguturi | I don't think I have it. Will check Thanks | 23:34 |
| nacc | stanguturi: just going off of `man interfaces` | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!