| === shardy_afk is now known as shardy | ||
| === shardy is now known as shardy_lunch | ||
| === shardy_lunch is now known as shardy | ||
| jsheeren | hi all, is there a way to detect if a cloud init has failed, besides polling the log? | 14:34 |
|---|---|---|
| rharper | jsheeren: yeah, /var/lib/cloud/data/{result,status}.json | 14:35 |
| smoser | jsheeren, and those are in /run/cloud-init/ also. i think thats probably preferred place as /var/lib/ could be stale | 14:36 |
| jsheeren | aha! thanks! | 14:37 |
| 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:42 |
| rharper | I don't think there's any sort of run this on failure in cloud-init directly; | 14:43 |
| rharper | I suggest looking at using an inotify watch on those files to get a trigger when they're written | 14:44 |
| jsheeren | rharper: ok, thanks, i'm going to look into that | 14:45 |
| smoser | result will be written only once, and atomicly | 14:47 |
| smoser | but only if cloud-init-final ran | 14:48 |
| smoser | status is written with each stage. | 14:48 |
| === rangerpbzzzz is now known as rangerpb | ||
| 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:24 |
| rharper | smoser: commented | 16:30 |
| powersj | magicalChicken: if I start working on the KVM code without some of your new branches, how much hurt will that be? | 16:35 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| magicalChicken | yeah, that's the main thing right now | 16:55 |
| smoser | /o\ | 16:56 |
| 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:57 |
| 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:58 |
| 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 | 16:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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? | 17:05 |
| 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:08 |
| 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:09 |
| 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 | 18:10 |
| 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:32 |
| smoser | render_factory.select_renderer() | 19:33 |
| rharper | smoser: and in my branch, I'll insert the netplan stuff | 19:43 |
| 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 | 19:45 |
| 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:26 |
| Odd_Bloke | Aha, using "user:" rather than "users:" works. | 21:31 |
| === rangerpb is now known as rangerpbzzzz | ||
| 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? | 21:56 |
| rharper | smoser: ok, pushed v2 netconfig branch again, reasonable unittests for v2 rendering and other places; | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!