Open Stack

On 4/09/18 5:39 PM, Ben Nemec wrote:
> 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. We started discussing this today and immediately realised it was 
going to result in every project copy/pasting the code to create a 
<project>-status executable and thae upgrade-check command itself. It 
would be great if we can avoid this from the start.

> 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/
>>
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev