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