<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 25 Apr 2019 at 23:50, Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/24/2019 8:21 AM, Mark Goddard wrote:<br>
> I put together a patch for kolla-ansible with support for upgrade checks <br>
> for some projects: <a href="https://review.opendev.org/644528" rel="noreferrer" target="_blank">https://review.opendev.org/644528</a>. It's on the <br>
> backburner at the moment but I plan to return to it during the Train <br>
> cycle. Perhaps you could clarify a few things about expected usage.<br>
<br>
Cool. I'd probably try to pick one service (nova?) to start with before <br>
trying to bite off all of these in a single change (that review is kind <br>
of daunting).<br>
<br>
Also, as part of the community wide goal I wrote up reference docs in <br>
the nova tree [1] which might answer your questions with links for more <br>
details.<br>
<br>
> <br>
> 1. Should the tool be run using the new code? I would assume so.<br>
<br>
Depends on what you mean by "new code". When nova introduced this in <br>
Ocata it was meant to be run in a venv or container after upgrading the <br>
newton schema and data migrations to ocata, but before restarting the <br>
services with the ocata code and that's how grenade uses it. But the <br>
checks should also be idempotent and can be run as a <br>
post-install/upgrade verify step, which is how OSA uses it (and is <br>
described in the nova install docs [2]).<br>
<br></blockquote><div><span class="gmail_default" style="font-family:verdana,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:verdana,sans-serif">In kolla land, I mean should I use the container image for the current release or the target release to execute the nova-status command. It sounds like it's the latter, which also implies we're using the target version of kolla/kolla-ansible. I hadn't twigged that we'd need to perform the schema upgrade and online migrations.</span></div><div><span class="gmail_default" style="font-family:verdana,sans-serif"></span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 2. How would you expect this to be run with multiple projects? I was <br>
> thinking of adding a new command that performs upgrade checks for all <br>
> projects that would be read-only, then also performing the check again <br>
> as part of the upgrade procedure.<br>
<br>
Hmm, good question. This probably depends on each deployment tool and <br>
how they roll through services to do the upgrade. Obviously you'd want <br>
to run each project's checks as part of upgrading that service, but I <br>
guess you're looking for some kind of "should we even start this whole <br>
damn upgrade if we can detect early that there are going to be issues?". <br>
If the early run is read-only though - and I'm assuming by read-only you <br>
mean they won't cause a failure - how are you going to expose that there <br>
is a problem without failing? Would you make that configurable? <br>
Otherwise the checks themselves are supposed to be read-only and not <br>
change your data (they aren't the same thing as an online data migration <br>
routine for example).<br>
<br></blockquote><div><span class="gmail_default" style="font-family:verdana,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:verdana,sans-serif">If we need to have run the schema upgrade and migrations before the upgrade check, I think that reduces the usefulness of a separate check operation. I was thinking you might be able to run the checks against the system prior to making any upgrade changes, but it seems not. I guess a separate check after the upgrade might still be useful for diagnosing upgrade issues from warnings.</span></div><div><span class="gmail_default" style="font-family:verdana,sans-serif"></span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 3. For the warnings, would you recommend a -Werror style argument that <br>
> optionally flags up warnings as errors? Reporting non-fatal errors is <br>
> quite difficult in Ansible.<br>
<br>
OSA fails on any return codes that aren't 0 (success) or 1 (warning). <br>
It's hard to say when warning should be considered an error really. When <br>
writing these checks I think of warning as a case where you might be OK <br>
but we don't really know for sure, so it can aid in debugging <br>
upgrade-related issues after the fact but might not necessarily mean you <br>
shouldn't upgrade. mnaser has brought up the idea in the past of making <br>
the output more machine readable so tooling could pick and choose which <br>
things it considers to be a failure (assuming the return code was 1). <br>
That's an interesting idea but one I haven't put a lot of thought into. <br>
It might be as simple as outputting a unique code per check per project, <br>
sort of like the error code concept in the API guidelines [3] which the <br>
placement project is using [4].<br>
<br></blockquote><div><span class="gmail_default" style="font-family:verdana,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:verdana,sans-serif">Machine readable would be nice. Perhaps there's something we could do to generate a report</span> <span class="gmail_default" style="font-family:verdana,sans-serif">of the combined results.</span></div><div><span class="gmail_default" style="font-family:verdana,sans-serif"></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[1] <a href="https://docs.openstack.org/nova/latest/reference/upgrade-checks.html" rel="noreferrer" target="_blank">https://docs.openstack.org/nova/latest/reference/upgrade-checks.html</a><br>
[2] <a href="https://docs.openstack.org/nova/latest/install/verify.html" rel="noreferrer" target="_blank">https://docs.openstack.org/nova/latest/install/verify.html</a><br>
[3] <a href="https://specs.openstack.org/openstack/api-wg/guidelines/errors.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/api-wg/guidelines/errors.html</a><br>
[4] <br>
<a href="https://opendev.org/openstack/placement/src/branch/master/placement/errors.py" rel="noreferrer" target="_blank">https://opendev.org/openstack/placement/src/branch/master/placement/errors.py</a><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
</blockquote></div></div>