Open Stack

On Mon, 15 Apr 2019 at 22:01, Matt Riedemann <mriedemos at gmail.com> wrote:

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

I put together a patch for kolla-ansible with support for upgrade checks
for some projects: https://review.opendev.org/644528. 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.

1. Should the tool be run using the new code? I would assume so.
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.
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.


> [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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/7fbe5037/attachment-0001.html>