[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].


 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.


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: 
[4] https://docs.openstack.org/oslo.upgradecheck/latest/
[5] https://review.openstack.org/#/c/575125/




More information about the openstack-discuss mailing list