| otubo | Odd_Bloke: Yes it did work! I'll open a PR for that. While we don't merge it and have it backported I'll keep that patch downstream for Fedora. | 10:26 |
|---|---|---|
| otubo | Odd_Bloke: thanks! | 10:26 |
| smoser | someone really should look at https://github.com/canonical/cloud-init/pull/691 | 14:21 |
| smoser | that is a big deal. that is vmware saying "here, we changed our platform to better serve cloud-init". | 14:21 |
| smoser | i think there are one or two users of vmware in the world. | 14:21 |
| blackboxsw | +1 smoser rick as asking one of us to look this over yesterday | 14:23 |
| blackboxsw | he wanted to gauge impact/risk | 14:24 |
| falcojr | blackboxsw: 2 PRs for you | 16:51 |
| blackboxsw | falcojr: fire away | 16:52 |
| falcojr | https://github.com/canonical/cloud-init/pull/711 a simple change to allow us to keep images as requested yesterday | 16:52 |
| falcojr | and https://github.com/canonical/cloud-init/pull/712 , another test | 16:52 |
| blackboxsw | falcojr: clarification question: generally for a single full integration test run, the test image is shared across multiple test cases right? | 16:53 |
| blackboxsw | this just allows you to preserve it even once the test suite is done running right? | 16:54 |
| falcojr | yep | 16:54 |
| blackboxsw | ok good, thx | 16:54 |
| blackboxsw | falcojr: https://github.com/canonical/cloud-init/pull/712/files#r536304908 | 18:46 |
| blackboxsw | one question here about how we generally expect the integration tests to run for SRU manual testing. I *think* we should be strict about expecting no errors across reboots in most tests. or explicitly check that cloud-init status didn't report error after the reboot completes. Not sure what you'd prefer there | 18:47 |
| falcojr | OK, I can add some error checking too. | 18:55 |
| falcojr | blackboxsw: do you think passing through "raise_on_failure" to the restart would be sufficient? | 19:47 |
| falcojr | it'll raise if "cloud-init status --wait --long" returns non-zero, but I don't know offhand the conditions it would return non-0 | 19:47 |
| blackboxsw | falcojr: it would return non-0 if we had tracebacks/errors in the cloud-init logs on the new clean boot. which I think is exactly what we want to gate against | 19:48 |
| falcojr | ok, cool, I'll add the option to pass it through then | 19:49 |
| blackboxsw | and I think passing through raise_on_failure to IntregrationInstance.restart is good | 19:49 |
| blackboxsw | yeah the only time we do want to hide restart errors on restart(which seems to be our default setting) is if we are expecting to validate a failure case | 19:49 |
| blackboxsw | I expect a trusty -> xenial upgrade of cloud-init to return a non-zero after reboot per this bug: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1899299 | 19:50 |
| ubot5 | Ubuntu bug 1899299 in cloud-init (Ubuntu) "do-release-upgrade from Trusty to Xenial breaks cloud-init init-local on reboot" [Undecided,Triaged] | 19:50 |
| blackboxsw | or if we are launching a with userdata that we know will fail prior to upgrading to cloud-init from -proposed | 19:51 |
| blackboxsw | falcojr: landed https://github.com/canonical/cloud-init/pull/712 | 20:55 |
| blackboxsw | thanks | 20:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!