<div dir="ltr"><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 Mon, 15 Apr 2019 at 22:01, 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">Now that Stein is GA I figured I'd write up a quick retrospective for <br>
the upgrade-checkers goal [1].<br>
<br>
Statistics<br>
----------<br>
<br>
From the tasks in the story [2]:<br>
<br>
- There were 52 total tasks.<br>
- Merged: 40<br>
- Review: 4 (still open)<br>
- Invalid: 8* (not applicable or opted out)<br>
<br>
Excluding Invalid tasks, the overall completion percentage of the goal <br>
was 91% which is pretty good. Granted, the majority of projects just <br>
added the placeholder framework for the upgrade check command which is <br>
not very useful for operators, but it's a start for those projects to <br>
build in real checks later.<br>
<br>
*5 of the Invalid tasks were for deployment projects which were not a <br>
target for the goal [3]. The others were for swift, telemetry and panko.<br>
<br>
oslo library<br>
------------<br>
<br>
To ease development, Ben Nemec extracted the framework of the nova check <br>
code into the oslo.upgradecheck library [4]. This made getting the <br>
framework in place for all projects much easier and ensures a high level <br>
of consistency in the command structure which is really important with <br>
this type of thing. Thanks again Ben!<br>
<br>
Not universal<br>
-------------<br>
<br>
As mentioned above, not all projects implemented the command since it <br>
maybe didn't make sense for those projects (swift, mistral and adjutant <br>
are good examples) and other projects just aren't in a place <br>
development-wise to put much priority in the goal (telemetry and panko).<br>
<br>
Extension points<br>
----------------<br>
<br>
Neutron created an extension point for their upgrade checks to support <br>
stadium projects and have already been using it. This was not something <br>
I thought about when we started the goal so it was cool that the neutron <br>
team embraced this and put their own spin on it.<br>
<br>
Contributions from NEC developers<br>
---------------------------------<br>
<br>
Akhil Jain and Rajat Dhasmana from NEC volunteered to add the framework <br>
of the command in most projects which was extremely helpful. Thank you <br>
Akhil and Rajat, and NEC for providing development resources to work on <br>
a cross-community goal like this.<br>
<br>
Next<br>
----<br>
<br>
While most projects have the framework in place for upgrade checks, a <br>
lot of projects released Stein with a simple placeholder check. A few <br>
projects have started adding real checks to aid in upgrades to Stein, <br>
which is great. I'm hopeful that other projects will add real checks as <br>
they encounter upgrade issues during Train development and need a way to <br>
signal those changes to operators in an automated way. Remember: if <br>
you're adding an upgrades release note, consider if you can automate <br>
that note.<br>
<br>
Another next step is to get deployment projects to build in a call to <br>
each project's upgrade check command because without deployment projects <br>
using the tool it doesn't serve much purpose. Let me note that this does <br>
not need to be driven by the deployment projects either - developers <br>
from each project can integrate their check into a deployment project of <br>
choice, like I did for OpenStack-Ansible [5]. I'm sure the deployment <br>
project dev teams would appreciate the service project teams driving <br>
this work.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I put together a patch for kolla-ansible with support for upgrade checks for some projects: <a href="https://review.opendev.org/644528">https://review.opendev.org/644528</a>. It's on the backburner at the moment but I plan to return to it during the Train cycle. Perhaps you could clarify a few things about expected usage.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">1. Should the tool be run using the new code? I would assume so.</div><div class="gmail_default" style="font-family:verdana,sans-serif">2. How would you expect this to be run with multiple projects? I was thinking of adding a new command that performs upgrade checks for all projects that would be read-only, then also performing the check again as part of the upgrade procedure.</div><div class="gmail_default" style="font-family:verdana,sans-serif">3. For the warnings, would you recommend a -Werror style argument that optionally flags up warnings as errors? Reporting non-fatal errors is quite difficult in Ansible.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
[1] <a href="https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html</a><br>
[2] <a href="https://storyboard.openstack.org/#!/story/2003657" rel="noreferrer" target="_blank">https://storyboard.openstack.org/#!/story/2003657</a><br>
[3] See the note: <br>
<a href="https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html#completion-criteria" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html#completion-criteria</a><br>
[4] <a href="https://docs.openstack.org/oslo.upgradecheck/latest/" rel="noreferrer" target="_blank">https://docs.openstack.org/oslo.upgradecheck/latest/</a><br>
[5] <a href="https://review.openstack.org/#/c/575125/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/575125/</a><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<br>
</blockquote></div></div></div>