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/ > > > __________________________________________________________________________ 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