[dev][qa][devstack] Release management for QA toold and plugins
Hi, QA folks, The release management team has been conducting a review of OpenStack official deliverables, to make sure nothing was falling between the cracks release-management-wise. As part of that review, we added a "release-management:" key to deliverables defined in the project governance repository in case they were not to be handled by the release management team using the openstack/releases repository. For example, some deliverables (like docs) are continuously published and therefore marked "release-management:none". Others (like charms) are released manually on 3rd-party platforms and therefore marked "release-management:external". In that context, several QA-maintained tools or related repos are a bit in limbo: * eslint-config-openstack: used to be released regularly, but was never released since we introduced openstack/releases. Should we just consider it cycle-independent, or drop the repository from governance ? * devstack-vagrant: never released, no change over the past year. Is it meant to be released in the future (cycle-independent) or considered continuously published (release-management:none) or should it be retired ? * karma-subunit-reporter: saw some early releases two years ago but not in recent times. Should we just consider it cycle-independent, or drop the repository from governance ? * devstack-plugin-*: Some of those were branched using openstack/releases back in Queens, but only devstack-plugin-container. was branched in Rocky. Some consistency here would be good. Should those all be branched every cycle in the future, or should we just branch none of them and consider them all continuously published (release-management:none) ? * devstack-tools: saw some early releases two years ago but not in recent times. Should we just consider it cycle-independent, or consider it abandoned ? Thanks in advance for your guidance, -- Thierry Carrez (ttx) On behalf of the release management team
On 11/29/18 10:22 AM, Thierry Carrez wrote:
Hi, QA folks,
The release management team has been conducting a review of OpenStack official deliverables, to make sure nothing was falling between the cracks release-management-wise.
As part of that review, we added a "release-management:" key to deliverables defined in the project governance repository in case they were not to be handled by the release management team using the openstack/releases repository. For example, some deliverables (like docs) are continuously published and therefore marked "release-management:none". Others (like charms) are released manually on 3rd-party platforms and therefore marked "release-management:external".
In that context, several QA-maintained tools or related repos are a bit in limbo:
* eslint-config-openstack: used to be released regularly, but was never released since we introduced openstack/releases. Should we just consider it cycle-independent, or drop the repository from governance ?
* devstack-vagrant: never released, no change over the past year. Is it meant to be released in the future (cycle-independent) or considered continuously published (release-management:none) or should it be retired ?
* karma-subunit-reporter: saw some early releases two years ago but not in recent times. Should we just consider it cycle-independent, or drop the repository from governance ?
* devstack-plugin-*: Some of those were branched using openstack/releases back in Queens, but only devstack-plugin-container. was branched in Rocky. Some consistency here would be good. Should those all be branched every cycle in the future, or should we just branch none of them and consider them all continuously published (release-management:none) ?
For the messaging plugins, we had intended to start branching them every cycle: https://review.openstack.org/#/c/556602 It seems I forgot to submit the review to do so for the rocky release though. I'm not sure if it's too late to do that, but I submitted the review: https://review.openstack.org/620962 It's also on my end-of-release todo list now.
* devstack-tools: saw some early releases two years ago but not in recent times. Should we just consider it cycle-independent, or consider it abandoned ?
Thanks in advance for your guidance,
On Thu, Nov 29, 2018 at 05:22:48PM +0100, Thierry Carrez wrote:
Hi, QA folks,
The release management team has been conducting a review of OpenStack official deliverables, to make sure nothing was falling between the cracks release-management-wise.
As part of that review, we added a "release-management:" key to deliverables defined in the project governance repository in case they were not to be handled by the release management team using the openstack/releases repository. For example, some deliverables (like docs) are continuously published and therefore marked "release-management:none". Others (like charms) are released manually on 3rd-party platforms and therefore marked "release-management:external".
In that context, several QA-maintained tools or related repos are a bit in limbo:
* eslint-config-openstack: used to be released regularly, but was never released since we introduced openstack/releases. Should we just consider it cycle-independent, or drop the repository from governance ?
This is a cycle independent tool, it's the equivalent of hacking but for js code. I know that projects are still using it, even if it's not super active the rules are pretty static and haven't need an update in a while.
* devstack-vagrant: never released, no change over the past year. Is it meant to be released in the future (cycle-independent) or considered continuously published (release-management:none) or should it be retired ?
I'll wait for gmann to weigh in on retiring it or not, but it doesn't need releases, it's just a tool repo for deploying a VM and setting up devstack using vagrant. It hasn't been active in a couple years, personally I've never used it so I don't know if it even works still or not. I'd vote for retiring it, but I haven't paid attention to it in a long time, so maybe it's still useful.
* karma-subunit-reporter: saw some early releases two years ago but not in recent times. Should we just consider it cycle-independent, or drop the repository from governance ?
This is also cycle independent, it's a tool for generating subunit streams from karma test runs. It's something we use for js unit tests and getting results into openstack-health and similar tools. It's also used externally a couple places.
* devstack-plugin-*: Some of those were branched using openstack/releases back in Queens, but only devstack-plugin-container. was branched in Rocky. Some consistency here would be good. Should those all be branched every cycle in the future, or should we just branch none of them and consider them all continuously published (release-management:none) ?
These would only ever be branched, since like devstack there aren't actually releases for it, just branches. As for the status of the plugins different ones are maintained by different teams depending on the plugins. I know a few fall under QA, but I personally don't know the status of them or whether they still work or not.
* devstack-tools: saw some early releases two years ago but not in recent times. Should we just consider it cycle-independent, or consider it abandoned ?
This is a package that is also cycle-independent, it's a support tool for devstack which is still used there. It just performs some operations which were much easier to write in python then in bash (mainly around manipulating config files iirc). Its usage is pretty stable right now so we haven't needed to release it in a while. -Matt Treinish
---- On Fri, 30 Nov 2018 04:16:36 +0900 Matthew Treinish <mtreinish@kortar.org> wrote ----
On Thu, Nov 29, 2018 at 05:22:48PM +0100, Thierry Carrez wrote:
Hi, QA folks,
The release management team has been conducting a review of OpenStack official deliverables, to make sure nothing was falling between the cracks release-management-wise.
As part of that review, we added a "release-management:" key to deliverables defined in the project governance repository in case they were not to be handled by the release management team using the openstack/releases repository. For example, some deliverables (like docs) are continuously published and therefore marked "release-management:none". Others (like charms) are released manually on 3rd-party platforms and therefore marked "release-management:external".
In that context, several QA-maintained tools or related repos are a bit in limbo:
* eslint-config-openstack: used to be released regularly, but was never released since we introduced openstack/releases. Should we just consider it cycle-independent, or drop the repository from governance ?
This is a cycle independent tool, it's the equivalent of hacking but for js code. I know that projects are still using it, even if it's not super active the rules are pretty static and haven't need an update in a while.
Yeah, This and other few QA tools are kind of not required much development and static but they are being used. As matt mentioned, they are cycle independent tool and get a release on the need basis. As they do not require much resource bandwidth and might be used by someone, there is no harm to keeping them in QA. I am not sure which release tag we should give to them ("release-management:none" and "release-management:external" does not fit for them) but I am ok to keep their release model as it is and give some appropriate tag.
* devstack-vagrant: never released, no change over the past year. Is it meant to be released in the future (cycle-independent) or considered continuously published (release-management:none) or should it be retired ?
I'll wait for gmann to weigh in on retiring it or not, but it doesn't need releases, it's just a tool repo for deploying a VM and setting up devstack using vagrant. It hasn't been active in a couple years, personally I've never used it so I don't know if it even works still or not. I'd vote for retiring it, but I haven't paid attention to it in a long time, so maybe it's still useful.
I am ok to retire this based on no one using it. And honestly saying, it is hard to judge that no one using it especially from the users who are not engaged in community communication etc. But i can start the ML and summit/PTG discussion to check its usage and then take the decision.
* karma-subunit-reporter: saw some early releases two years ago but not in recent times. Should we just consider it cycle-independent, or drop the repository from governance ?
This is also cycle independent, it's a tool for generating subunit streams from karma test runs. It's something we use for js unit tests and getting results into openstack-health and similar tools. It's also used externally a couple places.
ditto as eslint-config-openstack.
* devstack-plugin-*: Some of those were branched using openstack/releases back in Queens, but only devstack-plugin-container. was branched in Rocky. Some consistency here would be good. Should those all be branched every cycle in the future, or should we just branch none of them and consider them all continuously published (release-management:none) ?
These would only ever be branched, since like devstack there aren't actually releases for it, just branches. As for the status of the plugins different ones are maintained by different teams depending on the plugins. I know a few fall under QA, but I personally don't know the status of them or whether they still work or not.
I am not aware of all plugins but plugins under QA are: - devstack-plugin-container - as you mentioned, it is branched. - devstack-plugin-ceph - This is branchless. About branching them consistently, I will say it depends on plugin scope whether that needs to be branched or not. For example, devstack-plugin-ceph was not required as branched as no branch specific things in that. ceph configuration is all same for all branch. Doing branch on this will be unnecessary work.
* devstack-tools: saw some early releases two years ago but not in recent times. Should we just consider it cycle-independent, or consider it abandoned ?
This is a package that is also cycle-independent, it's a support tool for devstack which is still used there. It just performs some operations which were much easier to write in python then in bash (mainly around manipulating config files iirc). Its usage is pretty stable right now so we haven't needed to release it in a while.
Ditto as eslint-config-openstack -gmann
-Matt Treinish
On Thu, Nov 29, 2018 at 6:39 PM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
* devstack-vagrant: never released, no change over the past year. Is it meant to be released in the future (cycle-independent) or considered continuously published (release-management:none) or should it be retired ?
I am ok to retire this based on no one using it.
I actually use devstack-vagrant and find it useful to setup consistent devstack environments with minimal effort. Duc
---- On Fri, 30 Nov 2018 14:29:24 +0900 Duc Truong <duc.openstack@gmail.com> wrote ----
On Thu, Nov 29, 2018 at 6:39 PM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
* devstack-vagrant: never released, no change over the past year. Is it meant to be released in the future (cycle-independent) or considered continuously published (release-management:none) or should it be retired ?
I am ok to retire this based on no one using it.
I actually use devstack-vagrant and find it useful to setup consistent devstack environments with minimal effort.
Ok, then we can keep that. I will be happy to add you as maintainer of that if you would like to. I saw you have done some commit and review in Tempest and will be good to have you as devstack-vagrant . -gmann
Duc
Ghanshyam Mann wrote:
---- On Fri, 30 Nov 2018 14:29:24 +0900 Duc Truong <duc.openstack@gmail.com> wrote ----
On Thu, Nov 29, 2018 at 6:39 PM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
* devstack-vagrant: never released, no change over the past year. Is it meant to be released in the future (cycle-independent) or considered continuously published (release-management:none) or should it be retired ?
I am ok to retire this based on no one using it.
I actually use devstack-vagrant and find it useful to setup consistent devstack environments with minimal effort.
Ok, then we can keep that. I will be happy to add you as maintainer of that if you would like to. I saw you have done some commit and review in Tempest and will be good to have you as devstack-vagrant .
OK so in summary: eslint-config-openstack, karma-subunit-reporter, devstack-tools -> should be considered cycle-independent (with older releases history imported). Any future release would be done through openstack/releases devstack-vagrant -> does not need releases or release management, will be marked release-management:none in governance devstack-plugin-ceph -> does not need releases or cycle-related branching, so will be marked release-management:none in governance Other devstack-plugins maintainers should pick whether they need to be branched every cycle or not. Oslo-maintained plugins like devstack-plugin-zmq and devstack-plugin-pika will, for example. Unless someone objects, I'll push the related changes where needed. Thanks for the clarification ! -- Thierry Carrez (ttx)
On 11/30/18 4:05 AM, Thierry Carrez wrote:
Ghanshyam Mann wrote:
---- On Fri, 30 Nov 2018 14:29:24 +0900 Duc Truong <duc.openstack@gmail.com> wrote ---- > On Thu, Nov 29, 2018 at 6:39 PM Ghanshyam Mann <gmann@ghanshyammann.com> wrote: > > > > > > * devstack-vagrant: never released, no change over the past year. Is it > > > > meant to be released in the future (cycle-independent) or considered > > > > continuously published (release-management:none) or should it be retired ? > > > > > > > I am ok to retire this based on no one using it. > > I actually use devstack-vagrant and find it useful to setup consistent > devstack environments with minimal effort.
Ok, then we can keep that. I will be happy to add you as maintainer of that if you would like to. I saw you have done some commit and review in Tempest and will be good to have you as devstack-vagrant .
OK so in summary:
eslint-config-openstack, karma-subunit-reporter, devstack-tools -> should be considered cycle-independent (with older releases history imported). Any future release would be done through openstack/releases
devstack-vagrant -> does not need releases or release management, will be marked release-management:none in governance
devstack-plugin-ceph -> does not need releases or cycle-related branching, so will be marked release-management:none in governance
Other devstack-plugins maintainers should pick whether they need to be branched every cycle or not. Oslo-maintained plugins like devstack-plugin-zmq and devstack-plugin-pika will, for example.
Oh right, those exist too. :-) Both the zmq and pika drivers have been removed from oslo.messaging so those two repos can actually be retired once we no longer ci releases that contain the drivers. In the meantime there isn't any need to branch them since there isn't any development going on. Not sure whether that affects your plans but I thought I should clarify our plans for those two repos.
Unless someone objects, I'll push the related changes where needed. Thanks for the clarification !
Ben Nemec wrote:
On 11/30/18 4:05 AM, Thierry Carrez wrote:
[...] Other devstack-plugins maintainers should pick whether they need to be branched every cycle or not. Oslo-maintained plugins like devstack-plugin-zmq and devstack-plugin-pika will, for example.
Oh right, those exist too. :-)
Both the zmq and pika drivers have been removed from oslo.messaging so those two repos can actually be retired once we no longer ci releases that contain the drivers. In the meantime there isn't any need to branch them since there isn't any development going on.
Not sure whether that affects your plans but I thought I should clarify our plans for those two repos.
Thanks, I was indeed confused and filed https://review.openstack.org/621245 to revert. We probably need a specific release-management:no-more-needed or something to track such things that are not released anymore but are not ripe for removal just yet... -- Thierry Carrez (ttx)
---- On Fri, 30 Nov 2018 19:05:36 +0900 Thierry Carrez <thierry@openstack.org> wrote ----
Ghanshyam Mann wrote:
---- On Fri, 30 Nov 2018 14:29:24 +0900 Duc Truong <duc.openstack@gmail.com> wrote ----
On Thu, Nov 29, 2018 at 6:39 PM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
* devstack-vagrant: never released, no change over the past year. Is it meant to be released in the future (cycle-independent) or considered continuously published (release-management:none) or should it be retired ?
I am ok to retire this based on no one using it.
I actually use devstack-vagrant and find it useful to setup consistent devstack environments with minimal effort.
Ok, then we can keep that. I will be happy to add you as maintainer of that if you would like to. I saw you have done some commit and review in Tempest and will be good to have you as devstack-vagrant .
OK so in summary:
eslint-config-openstack, karma-subunit-reporter, devstack-tools -> should be considered cycle-independent (with older releases history imported). Any future release would be done through openstack/releases
devstack-vagrant -> does not need releases or release management, will be marked release-management:none in governance
devstack-plugin-ceph -> does not need releases or cycle-related branching, so will be marked release-management:none in governance
Other devstack-plugins maintainers should pick whether they need to be branched every cycle or not. Oslo-maintained plugins like devstack-plugin-zmq and devstack-plugin-pika will, for example.
Unless someone objects, I'll push the related changes where needed. Thanks for the clarification !
+1. Those looks good. Thanks. -gmann
-- Thierry Carrez (ttx)
Ghanshyam Mann wrote:
---- On Fri, 30 Nov 2018 19:05:36 +0900 Thierry Carrez <thierry@openstack.org> wrote ----
[...] OK so in summary:
eslint-config-openstack, karma-subunit-reporter, devstack-tools -> should be considered cycle-independent (with older releases history imported). Any future release would be done through openstack/releases
devstack-vagrant -> does not need releases or release management, will be marked release-management:none in governance
devstack-plugin-ceph -> does not need releases or cycle-related branching, so will be marked release-management:none in governance
Other devstack-plugins maintainers should pick whether they need to be branched every cycle or not. Oslo-maintained plugins like devstack-plugin-zmq and devstack-plugin-pika will, for example.
Unless someone objects, I'll push the related changes where needed. Thanks for the clarification !
+1. Those looks good. Thanks.
See: https://review.openstack.org/622903 https://review.openstack.org/622904 https://review.openstack.org/#/c/622919/ Cheers, -- Thierry Carrez (ttx)
participants (5)
-
Ben Nemec
-
Duc Truong
-
Ghanshyam Mann
-
Matthew Treinish
-
Thierry Carrez