Re: [openstack-dev] [goals][upgrade-checkers] Week R-31 update
On 09/12/2018 01:57 PM, Doug Hellmann wrote: Excerpts from Ben Nemec's message of 2018-09-12 13:51:16 -0600: On 09/04/2018 06:49 PM, Matt Riedemann wrote: On 9/4/2018 6: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. Yeah I'm not opposed to trying to pull the nova stuff into a common library for easier consumption in other projects, I just haven't devoted the time for it, nor will I probably have the time to do it. If others are willing to investigate that it would be great. Okay, here's a first shot at such a library: https://github.com/cybertron/oslo.upgradecheck Lots of rough edges that would need to be addressed before it could be released, but it demonstrates the basic idea I had in mind for this. The upgradecheck module contains the common code, and __main__.py is a demo use of the code. -Ben Nice! Let's get that imported into gerrit and keep iterating on it to make it usable for the goal. Maybe we can get one of the projects most interested in working on this goal early to help with testing and UX feedback. Okay, I got all the test jobs working and even added a few basic unit tests. I think it's about ready for import so I'll take a look at doing that soon. __ 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
Re: [openstack-dev] [goals][upgrade-checkers] Week R-31 update
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 -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
Re: [openstack-dev] [goals][upgrade-checkers] Week R-31 update
Excerpts from Ben Nemec's message of 2018-09-12 13:51:16 -0600: > > On 09/04/2018 06:49 PM, Matt Riedemann wrote: > > On 9/4/2018 6: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. > > > > Yeah I'm not opposed to trying to pull the nova stuff into a common > > library for easier consumption in other projects, I just haven't devoted > > the time for it, nor will I probably have the time to do it. If others > > are willing to investigate that it would be great. > > > > Okay, here's a first shot at such a library: > https://github.com/cybertron/oslo.upgradecheck > > Lots of rough edges that would need to be addressed before it could be > released, but it demonstrates the basic idea I had in mind for this. The > upgradecheck module contains the common code, and __main__.py is a demo > use of the code. > > -Ben > Nice! Let's get that imported into gerrit and keep iterating on it to make it usable for the goal. Maybe we can get one of the projects most interested in working on this goal early to help with testing and UX feedback. Doug __ 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
Re: [openstack-dev] [goals][upgrade-checkers] Week R-31 update
On 09/04/2018 06:49 PM, Matt Riedemann wrote: On 9/4/2018 6: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. Yeah I'm not opposed to trying to pull the nova stuff into a common library for easier consumption in other projects, I just haven't devoted the time for it, nor will I probably have the time to do it. If others are willing to investigate that it would be great. Okay, here's a first shot at such a library: https://github.com/cybertron/oslo.upgradecheck Lots of rough edges that would need to be addressed before it could be released, but it demonstrates the basic idea I had in mind for this. The upgradecheck module contains the common code, and __main__.py is a demo use of the code. -Ben __ 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
Re: [openstack-dev] [goals][upgrade-checkers] Week R-31 update
On 9/4/2018 6: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. Yeah I'm not opposed to trying to pull the nova stuff into a common library for easier consumption in other projects, I just haven't devoted the time for it, nor will I probably have the time to do it. If others are willing to investigate that it would be great. -- Thanks, Matt __ 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
Re: [openstack-dev] [goals][upgrade-checkers] Week R-31 update
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
Re: [openstack-dev] [goals][upgrade-checkers] Week R-31 update
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. 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
