=== shardy_afk is now known as shardy === shardy is now known as shardy_lunch === shardy_lunch is now known as shardy [14:34] hi all, is there a way to detect if a cloud init has failed, besides polling the log? [14:35] jsheeren: yeah, /var/lib/cloud/data/{result,status}.json [14:36] jsheeren, and those are in /run/cloud-init/ also. i think thats probably preferred place as /var/lib/ could be stale [14:37] aha! thanks! [14:42] is there a config option somewhere where i can run a program when cloudinit fails? or is it best to write some sort of daemon who polls the /var/lib/cloud/data/{result,status}.jso files? [14:43] I don't think there's any sort of run this on failure in cloud-init directly; [14:44] I suggest looking at using an inotify watch on those files to get a trigger when they're written [14:45] rharper: ok, thanks, i'm going to look into that [14:47] result will be written only once, and atomicly [14:48] but only if cloud-init-final ran [14:48] status is written with each stage. === rangerpbzzzz is now known as rangerpb [16:24] rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/319943 woudl apprecate a review. it wont fix the root cause of bug 1671927 but it will fix something. [16:30] smoser: commented [16:35] magicalChicken: if I start working on the KVM code without some of your new branches, how much hurt will that be? [16:50] powersj: the signature for some of the platform methods changed [16:50] it would probably be best to just base it off the new integration-testing branch [16:51] magicalChicken: this one right? https://code.launchpad.net/~wesley-wiedenmeier/cloud-init/+git/cloud-init/+ref/integration-testing [16:51] powersj: also the image config format changed and the config handling changed, which would be an issue [16:51] powersj: yeah [16:52] if you want to start off of that, it should work out ok, i wont rebase again [16:52] so in terms of branches of yours we want to land there are 3? integration-testing, integration-testing-distor-features, and integration-testing-invocation-cleanup? [16:52] integration-testing and integration-testing-invocation-cleanup are the two ready right now [16:53] although i still need to rebase invocation-cleanup [16:53] the distro-features one i'm still debugging some test failures on centos [16:53] ok [16:53] oh what about integration-testing-pylxd? [16:53] oh, that one isn't needed, the pylxd fix is in the main integration-testing [16:54] ok [16:54] i should probably delete that one [16:54] ok, so for now we need smoser to look at integration-testing [16:55] yeah, that's the main thing right now [16:56] /o\ [16:57] is that the reverse of being excited? hands over ears? [16:57] lol [16:57] is your commit message still all correct ? [16:58] - when using 2.2 the test suite cannot complete large [16:58] runs without hitting the pylxd too many open files [16:58] issue, so 2.2 should only be used for development [16:58] smoser: no, thanks for catching that, i hadn't updated the commit message at the top yet [16:59] magicalChicken, but you think that the commit series is sane as they are ? [16:59] ie, i'm ok to do a pull of mlutiple commits in a series here. [16:59] yes, i think so [16:59] i've gone through and rewritteen all the commit messages to make sense from outside the integration-testing dev branch [17:00] and the commits in that series are all pretty well separated from each other [17:00] magicalChicken: why multiple tox entries? Do we really need the old one? [17:01] powersj: i can pull it out [17:01] yeah, i'd drop that. [17:01] +1 [17:01] sure, one minute [17:01] and i'd drop support for 2.1 as it seems generally broken [17:01] right? [17:02] smoser: yeah, it doesn't return command exit code which is pretty bad [17:02] if execute('/bin/false') blissfully goes on [17:02] do you have an reason for 'ignore_errors' rather than explicit values like subp ? [17:03] smoser: i could do something more along the lines of subp [17:03] ignore_errors == subp(['/bin/false'], rcs=range(0, 256)) [17:03] yeah, that gives us some more control when we need to ignore errors [17:04] ie, if i want to just ignore anything, thats pretty easy to do with an explicit list of rcs [17:04] and less surprises when somethign returned 14 and we only really expected 0 or 1 [17:04] currently the ignore errors is pretty much only used for the actual collect scripts. and i want to remove that eventually, but i haven't gone through all the collect scripts to see what the impact would be [17:04] dont worry about re-writing the commit message at the moment. [17:05] ok [17:05] i was going to rebase to pull out the tox env, do you want me to just add a new commit for it instead? [18:08] smoser: i pushed commits to remove the tox env and switch to rcs=(0,1) for execute(), should be ready to go now [18:08] magicalChicken: thanks! [18:09] ok. i'll oook a bit mroe [18:09] aah, it looks like i may have messed up a bit in the rcs 1, i'm going to amend that real quick [18:10] should be good to go now, i messed up the change in collect and didn't catch it until one of the tests failed a collect script [19:32] rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+ref/feature/net-render-priority [19:32] that is the branch i have. [19:32] smoser: cool [19:32] but from cloudinit.net import render_factory [19:33] render_factory.select_renderer() [19:43] smoser: and in my branch, I'll insert the netplan stuff [19:45] ok. i have to run for a while, probaly check back in later tonight. [19:45] ok [19:45] I should have an update pushed with unittests [21:26] smoser: Can I change the default username from {vendor,user}-data? I still want my renamed user to get the default SSH keys etc. [21:31] Aha, using "user:" rather than "users:" works. === rangerpb is now known as rangerpbzzzz [21:56] hello again. i'm having a problem similar to https://bugs.launchpad.net/cloud-init/+bug/1645597, but i'm on Openstack and ConfigDrive; should i log a new bug or just add on to this one? [23:54] smoser: ok, pushed v2 netconfig branch again, reasonable unittests for v2 rendering and other places;