Open Stack

Excerpts from Ben Nemec's message of 2018-09-04 18:39:35 -0500:
> Would it be helpful to factor some of the common code out into an Oslo 
> library so projects basically just have to subclass, implement check 
> functions, and add them to the _upgrade_checks dict? It's not a huge 
> amount of code, but a bunch of it seems like it would need to be 
> copy-pasted into every project. I have a tentative topic on the Oslo PTG 
> schedule for this but figured I should check if it's something we even 
> want to pursue.

+1 if there's reusable bits.

> 
> On 09/04/2018 04:29 PM, Matt Riedemann wrote:
> > Just a few updates this week.
> > 
> > 1. The story is now populated with a task per project that may have 
> > something to complete for this goal [1]. PTLs, or their liaison(s), 
> > should assign the task for their project to whomever is going to work on 
> > the goal. The goal document in governance is being updated with the 
> > appropriate links to storyboard [2].
> > 
> > 2. While populating the story and determining which projects to omit 
> > (like infra, docs, QA were obvious), I left in the deployment projects 
> > but those likely can/should opt-out of this goal for Stein since the 
> > goal is more focused on service projects like keystone/cinder/glance. I 
> > have pushed a docs updated to the goal with respect to deployment 
> > projects [3]. For deployment projects that don't plan on doing anything 
> > with this goal, feel free to just invalidate the task in storyboard for 
> > your project.
> > 
> > 3. I have a developer/contributor reference docs patch up for review in 
> > nova [4] which is hopefully written generically enough that it can be 
> > consumed by and used as a guide for other projects implementing these 
> > upgrade checks.
> > 
> > 4. I've proposed an amendment to the completion criteria for the goal 
> > [5] saying that projects with the "supports-upgrade" tag should 
> > integrate the checks from their project with their upgrade CI testing 
> > job. That could be grenade or some other upgrade testing framework, but 
> > it stands to reason that a project which claims to support upgrades and 
> > has automated checks for upgrades, should be running those in their CI.
> > 
> > Let me know if there are any questions. There will also be some time 
> > during a PTG lunch-and-learn session where I'll go over this goal at a 
> > high level, so feel free to ask questions during or after that at the 
> > PTG as well.
> > 
> > [1] https://storyboard.openstack.org/#!/story/2003657
> > [2] https://review.openstack.org/#/c/599759/
> > [3] https://review.openstack.org/#/c/599835/
> > [4] https://review.openstack.org/#/c/596902/
> > [5] https://review.openstack.org/#/c/599849/
> > 
>