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