[goals][upgrade-checkers] Retrospective
Matt Riedemann
mriedemos at gmail.com
Mon Apr 15 21:00:46 UTC 2019
Now that Stein is GA I figured I'd write up a quick retrospective for
the upgrade-checkers goal [1].
Statistics
----------
From the tasks in the story [2]:
- There were 52 total tasks.
- Merged: 40
- Review: 4 (still open)
- Invalid: 8* (not applicable or opted out)
Excluding Invalid tasks, the overall completion percentage of the goal
was 91% which is pretty good. Granted, the majority of projects just
added the placeholder framework for the upgrade check command which is
not very useful for operators, but it's a start for those projects to
build in real checks later.
*5 of the Invalid tasks were for deployment projects which were not a
target for the goal [3]. The others were for swift, telemetry and panko.
oslo library
------------
To ease development, Ben Nemec extracted the framework of the nova check
code into the oslo.upgradecheck library [4]. This made getting the
framework in place for all projects much easier and ensures a high level
of consistency in the command structure which is really important with
this type of thing. Thanks again Ben!
Not universal
-------------
As mentioned above, not all projects implemented the command since it
maybe didn't make sense for those projects (swift, mistral and adjutant
are good examples) and other projects just aren't in a place
development-wise to put much priority in the goal (telemetry and panko).
Extension points
----------------
Neutron created an extension point for their upgrade checks to support
stadium projects and have already been using it. This was not something
I thought about when we started the goal so it was cool that the neutron
team embraced this and put their own spin on it.
Contributions from NEC developers
---------------------------------
Akhil Jain and Rajat Dhasmana from NEC volunteered to add the framework
of the command in most projects which was extremely helpful. Thank you
Akhil and Rajat, and NEC for providing development resources to work on
a cross-community goal like this.
Next
----
While most projects have the framework in place for upgrade checks, a
lot of projects released Stein with a simple placeholder check. A few
projects have started adding real checks to aid in upgrades to Stein,
which is great. I'm hopeful that other projects will add real checks as
they encounter upgrade issues during Train development and need a way to
signal those changes to operators in an automated way. Remember: if
you're adding an upgrades release note, consider if you can automate
that note.
Another next step is to get deployment projects to build in a call to
each project's upgrade check command because without deployment projects
using the tool it doesn't serve much purpose. Let me note that this does
not need to be driven by the deployment projects either - developers
from each project can integrate their check into a deployment project of
choice, like I did for OpenStack-Ansible [5]. I'm sure the deployment
project dev teams would appreciate the service project teams driving
this work.
[1] https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html
[2] https://storyboard.openstack.org/#!/story/2003657
[3] See the note:
https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html#completion-criteria
[4] https://docs.openstack.org/oslo.upgradecheck/latest/
[5] https://review.openstack.org/#/c/575125/
--
Thanks,
Matt
More information about the openstack-discuss
mailing list