[10:26] <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!
[14:21] <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:23] <blackboxsw> +1 smoser rick as asking one of us to look this over yesterday
[14:24] <blackboxsw> he wanted to gauge impact/risk
[16:51] <falcojr> blackboxsw: 2 PRs for you
[16:52] <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:53] <blackboxsw> falcojr: clarification question: generally for a single full integration test run, the test image is shared across multiple test cases right?
[16:54] <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
[18:46] <blackboxsw> falcojr: https://github.com/canonical/cloud-init/pull/712/files#r536304908
[18:47] <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:55] <falcojr> OK, I can add some error checking too.
[19:47] <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:48] <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:49] <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:50] <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:51] <blackboxsw> or if we are launching a with userdata that we know will fail prior to upgrading to cloud-init from -proposed
[20:55] <blackboxsw> falcojr: landed https://github.com/canonical/cloud-init/pull/712
[20:56] <blackboxsw> thanks