=== cpaelzer_ is now known as cpaelzer
=== ddstreet_away is now known as ddstreet
[12:55] <otubo> smoser: what about adding an exception to cloud-init so user can still resize the LV? https://github.com/otubo/cloud-init/commit/1ce765d75f144c22814221bd9c16ae90a0e4e757
[12:56] <otubo> smoser: sorry force push to fix a typo https://github.com/otubo/cloud-init/commit/8cc6c035dea62f02cc82f655d2f118e3ab670c8b
=== hggdh_ is now known as hggdh
[13:41] <smoser> otubo: what od you mean adding an exception?
[13:56] <otubo> I mean, if the user configued a single device for growpart to grow, than we grow it (LV included), otherwise we fail with that log.
[13:56] <otubo> smoser:
[13:57] <otubo> smoser: I'll address those two comments, write the unittest and create a PR.
[14:39] <Odd_Bloke> blackboxsw: falcojr: We had specifically avoided raising on failure on initial boot of (all) instances so that our test assertions would run even if a failure case happened ("WARN found in cloud-init.log: ..." is a lot more useful than a traceback because cloud-init status exited non-zero).  I think the change in #712 makes sense, but wanted to flag up that this is not intended to "hide" errors.
[14:40] <falcojr> yep, I think we were agreed that was the right change. We just decided it was good to have the option when doing restarts in the middle of tests
[14:41] <Odd_Bloke> (I wonder if we should modify restart (and perhaps launch?) to perform some asserting themselves; that guarantees that we don't miss breakage on subsequent boots, but gives us better fidelity on such errors.)
[14:41] <Odd_Bloke> AnhVoMSFT: Still seeing that bionic tox failure?  Pastebin the error?
[16:23] <AnhVoMSFT> @Odd_Bloke yes error is still there https://paste.ubuntu.com/p/GXwYj33XgX/
[16:53] <blackboxsw> Odd_Bloke: I agree that the default makes sense to avoid non-specific failure cases due to warnings in general as we should be specifically asserting a given specific failure .   The upgrade test in this James' case was hoping to fail on any unexpected errors/warnings.
[16:53] <blackboxsw> Will look over that PR now
[17:00] <Odd_Bloke> blackboxsw: Right, I'm wondering if we should write some more specific assertions in the cloud-init codebase, rather than just relying on the exception raised by `cloud-init status --wait`; I guess now we capture logs on error, it's less important to have the assertions describe the problem accurately, however.
[17:00] <otubo> smoser: PR in https://github.com/canonical/cloud-init/pull/714 hopefully we can merge it until Friday, which is when I leave for vacation :-D
[17:01] <otubo> Odd_Bloke: your patch regarding the CA Cert tests are also in https://github.com/canonical/cloud-init/pull/715
[17:01] <blackboxsw> @Odd_Bloke I agree we should probably develop that specific error handling to avoid the generic exit code failure.
[17:03] <Odd_Bloke> AnhVoMSFT: Hmm, so I think the problem you're hitting is that the new pip dependency resolver isn't allowing httpretty 1.0.2 to be installed; that version fixes the error you're seeing there.
[17:04] <Odd_Bloke> So some other dependency is declaring an httpretty dependency which excludes 1.0.2 (and the new resolver is smart enough to therefore not install 1.0.2).
[17:04] <Odd_Bloke> But 1.0.1 is broken in a way which kills the resolver, it looks like.
[17:14] <blackboxsw> Odd_Bloke: I'm probably going down the wrong path related to your assertion comment. But, I do think we should grow the cloud-init status --wait error handling/assertions etc for better error handling and better user experience when failures occur. I think our 'cloud-init status --long' failures are cryptic at best and force folks to go spelunking into /var/log/cloud-init.log. It'd be nice to classify failures a
[17:14] <blackboxsw> bit better.
[17:14] <blackboxsw> and potentially give better warning handling there too
[17:14] <blackboxsw> falcojr: https://github.com/canonical/cloud-init/pull/693#discussion_r537675513
[17:14] <Odd_Bloke> AnhVoMSFT: We'll have to root cause exactly what's going on, but I think http://paste.ubuntu.com/p/FjCyFJTXZm/ applied locally should unblock you for now.
[17:15] <AnhVoMSFT> thanks @Odd_Bloke, let me try
[17:43] <blackboxsw> Odd_Bloke: smoser rharper , falcojr so we've cut SRU as of a week+ ago and uploaded cloud-init into Ubuntu -proposed pockets. I just wanted to notify folks that we are looking to land PRs that are not intended for SRU. So, if we see regressions during SRU validation, we will have to follow cloud-init's cherry-pick  process to pull down specific changes into the ubuntu/* release branches. Does that sound ok to
[17:43] <blackboxsw> all?
[17:44] <blackboxsw> I'm thinking about this PR[1] , but I know there are other feature-full changes (like VMware too) that we wouldn't want to incidentally pull in if we find a regression during cloud-init SRU testing. [1] https://github.com/canonical/cloud-init/pull/647
=== ijohnson is now known as ijohnson|lunch
[18:02] <blackboxsw> falcojr: upgrade test merged https://github.com/canonical/cloud-init/pull/693
[18:02] <blackboxsw> thanks
[19:00] <rharper> blackboxsw: yeah, that sounds fine;
=== ijohnson|lunch is now known as ijohnson
[23:58] <blackboxsw> got a rewiew in for vmware supporting cloud-config userdata & metadata for xiaofeng https://github.com/canonical/cloud-init/pull/691. that'll be fun when it landds