Re: [openstack-dev] [tc] [all] thinking additional tags
Thierry Carrez wrote: > The "next tags" workgroup will be having a meeting this week on Friday > at 14:00 UTC in #openstack-meeting. Join us if you're interested ! > > In the mean time, we are braindumping at: > https://etherpad.openstack.org/p/next-tags-wg The work group met 10 days ago and decided to tackle tags in the following categories: * Integration tags Those describe whether the project is integrated with something else. Sean Dague proposed to kick off this category with "devstack support" tags, and proposed them at https://review.openstack.org/#/c/203785/ * Team tags Team tags communicate whether the people behind a given project form a sustainable team. Russell Bryant agreed to draft tags about team size and team monoculture to further improve on our communication there. * Contract tags Contract tags are promises that project teams make about their deliverables. For example, I'll draft three tags describing feature/API deprecation policies that projects teams may opt to follow. These communicate clearly what to expect from a given project. In this same category, Zane Bitter will draft a tag about forward-compatible configuration files. * QA tags QA tags communicate what a given project actually tests. Does it do full stack testing, upgrade testing, partial upgrade testing ? * Horizontal team support tags These communicate which projects are directly supported by horizontal teams. We already have the "release:managed" tag and the "vulnerability:managed" tags to describe which projects are directly supported by the release management or the vulnerability management teams. I'll draft a tag to describe which projects have stable branches that follow the stable branch maintenance team policy. Sorry for the late report, -- Thierry Carrez (ttx) __ 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] [tc] [all] thinking additional tags
The "next tags" workgroup will be having a meeting this week on Friday at 14:00 UTC in #openstack-meeting. Join us if you're interested ! In the mean time, we are braindumping at: https://etherpad.openstack.org/p/next-tags-wg See you there, -- Thierry Carrez (ttx) __ 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] [tc] [all] thinking additional tags
On 08/07/15 18:12, Steve Baker wrote:
On 09/07/15 04:39, Zane Bitter wrote:
On 08/07/15 09:03, Sean Dague wrote:
Personally, I'm running out of steam on tags for this cycle, but Zane
brought up a good point in the TC meeting yesterday, which was that "it
would be nice to have tags for criteria that we used to use for
integration requirements". I strongly agree with that perspective.
A few ideas I was thinking about here from the areas that I poke at
quite often. I'm doing this on the ML as a lighter weight discussion
medium than gerrit as these are pretty raw brain droppings.
Devstack:
* some tag that stated if it was in_devstack or has_devstack_plugin. I
hesitate breaking those into 2, because it assumes value judgement that
one is better than the other. However, has_devstack_plugin is useful
information to know you need to add 1 line to your local.conf to enable
that service.
has_devstack_plugin has a very specific meaning that the project
implements this interface -
http://docs.openstack.org/developer/devstack/plugins.html
+1
Equivalents for Horizon & Heat were part of the 'First cycle
expectations' list, and I believe would be helpful too. I'd also like
to see one for python-openstackclient and another for the SDK. We
could do something similar for other projects that use plugins too,
like Mistral.
Ceilometer integration was also on the 'First cycle expectations'
list, and would make a good tag. It also says "The lifecycle of
resources managed by the project should be externalized via
notifications so that they can be consumed by other integrated
projects", but I'm not sure what that means... I assume those are the
same notifications that Ceilometer reads? I guess it makes sense to
have two tags - one for notifications being sent and one for
Ceilometer knowing how to read them.
Who would be responsible for applying these tags? How about it happens
by joint agreement of the project receiving the tag and the relevant
tag owner (e.g. Devstack for has_devstack_plugin), as represented by
their respective PTLs?
For devstack and these other projects Zane has mentioned it would be
ideal to come up with a common convention for tags which designate that
another project has implemented that capability. And there would be some
value in distinguishing between in-tree and plugin support, since it has
deployment implications.
So as a starter, I'd like to suggest:
devstack:in-tree
devstack:plugin
heat:in-tree
heat:plugin
horizon:in-tree
horizon:plugin
openstackclient:in-tree
openstackclient:plugin
...etc
TBH I'd much rather get to a point where the distinction doesn't matter.
Preferably one where every plugin is treated equally - i.e. for any
given project, either all plugins are out-of-tree (I believe Horizon
have talked about going down this path) or all plugins are in-tree
(we've talked about doing this with Heat).
In the case of Heat for example, I think we'd only apply the tag to
projects with in-tree plugins and we'd encourage anybody with
out-of-tree plugins or appropriate /contrib plugins ('appropriate' here
meaning that they're driving APIs that are part of OpenStack) to get
them into the main tree so we could give them the tag.
cheers,
Zane.
I'm not sure if this would apply to ceilometer since I assume the
capability is always implemented in the project tree, so that tag could
be something like ceilometer:publishes-metrics.
These project-namespaced tags would all imply that it is up to the PTL
of the respective projects to come up with the process for proposing
these tags, and the TC has final approval.
QA:
* full_stack_testing - does the project have voting gate jobs that
bring up an OpenStack environment with it and some other selection of
OpenStack projects needed to test it. Basically, is the project doing
more than unit testing. (Possibly also specify that tests run parallel,
given that transition from serial to parallel testing has exposed real
bugs in nearly every project that's done that).
+1
Upgrade:
There are various qualities about upgrade that we'd like to see out of
projects, and highlight when they exist.
* no config change upgrades - the config file for N-1 works with N
* partial upgrades - N-1 and N components can exist simultaneously in a
cluster (allows for rolling upgrades)
* upgrade testing - changes are gated on a voting upgrade test
* partial upgrade testing - changes are gated on a voting partial
upgrade test
+1
Most of these are pretty objective, I think there are also items around
API contract, but that's actually a bit less objective, as we've seen
around the debates on whether or not there is such a thing as a
compatible API change with no user signaling in the microversion thread.
I think we need a stable-api-since tag, but we should leave it
entirely in the hands of the project teams themselves to apply. That
way it's up to the project to decide when it starts enforcing API
stability, and we have a clear way to communicate to u
Re: [openstack-dev] [tc] [all] thinking additional tags
Sean Dague wrote: > On 07/08/2015 12:51 PM, Thierry Carrez wrote: >> Sean Dague wrote: >>> Personally, I'm running out of steam on tags for this cycle, but Zane >>> brought up a good point in the TC meeting yesterday, which was that "it >>> would be nice to have tags for criteria that we used to use for >>> integration requirements". I strongly agree with that perspective. >>> [...] >> >> Thanks for bringing that up. As mentioned at the TC meeting yesterday I >> plan to set up a small TC workgroup to aggressively look for missing >> tags and define them. Russell already signed up, and as all TC >> workgroups it can include non-TC members (it's actually a great way to >> do succession planning at the TC). >> >> I'm still stuck on (re)defining the release tags to match the Liberty >> release models, but I plan to start working on that soon after. >> >> Who is in? > > Happy to help. I think turning this into a WG probably spreads the load > around a bit to prevent burnout. The WG is also about: * preparing tag submissions as a group rather than wait for an individual to care enough to propose one * pre-discussing issues at the WG level to remove load on the TC itself * having a more coherent vision overall The only reason we didn't do it before is that we already had a backlog of urgent tags to push. I think we are almost past that now and can spend more time designing the tag landscape. Personally I want to push "stability" tags that would define 3 levels of API/feature deprecation models for projects to commit to: 1- Will never ever deprecate an API or a feature ever, we are mature. 2- May remove APIs / features but will follow deprecation / removal N+2 rule, we are used in production but still developing. 3- May just remove anything anytime, we are very experimental. This is not a judgment call, every project team is free to select which model they commit to -- and I think it's VERY interesting information for our users, which was completely hidden below the binary "integrated release" (which had swift (1), nova (2) and ironic (3) at the same time). -- Thierry Carrez (ttx) __ 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] [tc] [all] thinking additional tags
On 07/08/2015 12:51 PM, Thierry Carrez wrote: > Sean Dague wrote: >> Personally, I'm running out of steam on tags for this cycle, but Zane >> brought up a good point in the TC meeting yesterday, which was that "it >> would be nice to have tags for criteria that we used to use for >> integration requirements". I strongly agree with that perspective. >> [...] > > Thanks for bringing that up. As mentioned at the TC meeting yesterday I > plan to set up a small TC workgroup to aggressively look for missing > tags and define them. Russell already signed up, and as all TC > workgroups it can include non-TC members (it's actually a great way to > do succession planning at the TC). > > I'm still stuck on (re)defining the release tags to match the Liberty > release models, but I plan to start working on that soon after. > > Who is in? Happy to help. I think turning this into a WG probably spreads the load around a bit to prevent burnout. -Sean -- Sean Dague http://dague.net __ 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] [tc] [all] thinking additional tags
On 07/08/2015 06:12 PM, Steve Baker wrote: > On 09/07/15 04:39, Zane Bitter wrote: >> On 08/07/15 09:03, Sean Dague wrote: >>> Personally, I'm running out of steam on tags for this cycle, but Zane >>> brought up a good point in the TC meeting yesterday, which was that "it >>> would be nice to have tags for criteria that we used to use for >>> integration requirements". I strongly agree with that perspective. >>> >>> A few ideas I was thinking about here from the areas that I poke at >>> quite often. I'm doing this on the ML as a lighter weight discussion >>> medium than gerrit as these are pretty raw brain droppings. >>> >>> Devstack: >>> >>> * some tag that stated if it was in_devstack or has_devstack_plugin. I >>> hesitate breaking those into 2, because it assumes value judgement that >>> one is better than the other. However, has_devstack_plugin is useful >>> information to know you need to add 1 line to your local.conf to enable >>> that service. >>> >>> has_devstack_plugin has a very specific meaning that the project >>> implements this interface - >>> http://docs.openstack.org/developer/devstack/plugins.html >> >> +1 >> >> Equivalents for Horizon & Heat were part of the 'First cycle >> expectations' list, and I believe would be helpful too. I'd also like >> to see one for python-openstackclient and another for the SDK. We >> could do something similar for other projects that use plugins too, >> like Mistral. >> >> Ceilometer integration was also on the 'First cycle expectations' >> list, and would make a good tag. It also says "The lifecycle of >> resources managed by the project should be externalized via >> notifications so that they can be consumed by other integrated >> projects", but I'm not sure what that means... I assume those are the >> same notifications that Ceilometer reads? I guess it makes sense to >> have two tags - one for notifications being sent and one for >> Ceilometer knowing how to read them. >> >> Who would be responsible for applying these tags? How about it happens >> by joint agreement of the project receiving the tag and the relevant >> tag owner (e.g. Devstack for has_devstack_plugin), as represented by >> their respective PTLs? >> > For devstack and these other projects Zane has mentioned it would be > ideal to come up with a common convention for tags which designate that > another project has implemented that capability. And there would be some > value in distinguishing between in-tree and plugin support, since it has > deployment implications. > > So as a starter, I'd like to suggest: > devstack:in-tree > devstack:plugin > heat:in-tree > heat:plugin > horizon:in-tree > horizon:plugin > openstackclient:in-tree > openstackclient:plugin +1 that seems pretty clear. When it comes to plugins we should make sure that there is very specific documentation in the Tag description about what it means to be a plugin, and how users enable them (which should be a global process for each kind of thing). > ...etc > > I'm not sure if this would apply to ceilometer since I assume the > capability is always implemented in the project tree, so that tag could > be something like ceilometer:publishes-metrics. > > These project-namespaced tags would all imply that it is up to the PTL > of the respective projects to come up with the process for proposing > these tags, and the TC has final approval. So, honestly, it feels like application of these things should be pretty automatic. In the devstack case, I could write a script to get the answer, because devstack plugins require a very specific directory structure in the project. If every project has different instructions about how to add themselves to horizon, that seems pretty anti user. If there is a framework in Horizon that means all projects follow the same instructions when being added, that is much better. And seems like could be basically scripted for detection. Mostly, I think the TC should hold off calling things plugins unless they have a pretty strict contract, and enabling interface. Because if we have those the difference between in-tree and plugin should be minimal from a user perspective, which supports the model of a big tent. (Note: I honestly don't know what the plugin interfaces look like for all the rest of these things, so I'm completely conjecturing. Writing up tag definitions that provide overview and pointers to them will be great cross learning for our whole community.) -Sean -- Sean Dague http://dague.net __ 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] [tc] [all] thinking additional tags
Quoting Thierry Carrez (2015-07-08 18:51:42) > Sean Dague wrote: > > Personally, I'm running out of steam on tags for this cycle, but Zane > > brought up a good point in the TC meeting yesterday, which was that "it > > would be nice to have tags for criteria that we used to use for > > integration requirements". I strongly agree with that perspective. > > [...] > > Thanks for bringing that up. As mentioned at the TC meeting yesterday I > plan to set up a small TC workgroup to aggressively look for missing > tags and define them. Russell already signed up, and as all TC > workgroups it can include non-TC members (it's actually a great way to > do succession planning at the TC). > > I'm still stuck on (re)defining the release tags to match the Liberty > release models, but I plan to start working on that soon after. > > Who is in? I'm in! Ghe Rivero > -- > Thierry Carrez (ttx) > > __ > 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] [tc] [all] thinking additional tags
On 09/07/15 04:39, Zane Bitter wrote: On 08/07/15 09:03, Sean Dague wrote: Personally, I'm running out of steam on tags for this cycle, but Zane brought up a good point in the TC meeting yesterday, which was that "it would be nice to have tags for criteria that we used to use for integration requirements". I strongly agree with that perspective. A few ideas I was thinking about here from the areas that I poke at quite often. I'm doing this on the ML as a lighter weight discussion medium than gerrit as these are pretty raw brain droppings. Devstack: * some tag that stated if it was in_devstack or has_devstack_plugin. I hesitate breaking those into 2, because it assumes value judgement that one is better than the other. However, has_devstack_plugin is useful information to know you need to add 1 line to your local.conf to enable that service. has_devstack_plugin has a very specific meaning that the project implements this interface - http://docs.openstack.org/developer/devstack/plugins.html +1 Equivalents for Horizon & Heat were part of the 'First cycle expectations' list, and I believe would be helpful too. I'd also like to see one for python-openstackclient and another for the SDK. We could do something similar for other projects that use plugins too, like Mistral. Ceilometer integration was also on the 'First cycle expectations' list, and would make a good tag. It also says "The lifecycle of resources managed by the project should be externalized via notifications so that they can be consumed by other integrated projects", but I'm not sure what that means... I assume those are the same notifications that Ceilometer reads? I guess it makes sense to have two tags - one for notifications being sent and one for Ceilometer knowing how to read them. Who would be responsible for applying these tags? How about it happens by joint agreement of the project receiving the tag and the relevant tag owner (e.g. Devstack for has_devstack_plugin), as represented by their respective PTLs? For devstack and these other projects Zane has mentioned it would be ideal to come up with a common convention for tags which designate that another project has implemented that capability. And there would be some value in distinguishing between in-tree and plugin support, since it has deployment implications. So as a starter, I'd like to suggest: devstack:in-tree devstack:plugin heat:in-tree heat:plugin horizon:in-tree horizon:plugin openstackclient:in-tree openstackclient:plugin ...etc I'm not sure if this would apply to ceilometer since I assume the capability is always implemented in the project tree, so that tag could be something like ceilometer:publishes-metrics. These project-namespaced tags would all imply that it is up to the PTL of the respective projects to come up with the process for proposing these tags, and the TC has final approval. QA: * full_stack_testing - does the project have voting gate jobs that bring up an OpenStack environment with it and some other selection of OpenStack projects needed to test it. Basically, is the project doing more than unit testing. (Possibly also specify that tests run parallel, given that transition from serial to parallel testing has exposed real bugs in nearly every project that's done that). +1 Upgrade: There are various qualities about upgrade that we'd like to see out of projects, and highlight when they exist. * no config change upgrades - the config file for N-1 works with N * partial upgrades - N-1 and N components can exist simultaneously in a cluster (allows for rolling upgrades) * upgrade testing - changes are gated on a voting upgrade test * partial upgrade testing - changes are gated on a voting partial upgrade test +1 Most of these are pretty objective, I think there are also items around API contract, but that's actually a bit less objective, as we've seen around the debates on whether or not there is such a thing as a compatible API change with no user signaling in the microversion thread. I think we need a stable-api-since tag, but we should leave it entirely in the hands of the project teams themselves to apply. That way it's up to the project to decide when it starts enforcing API stability, and we have a clear way to communicate to users when that happened. (Previously, integrated projects were required to have stable APIs and any project not in the integrated release could be presumed not to.) Another possibility would be tags to indicate that a project uses oslo.config and oslo.log. (There may be other Oslo libraries that have a significant operator-facing interface impact, if anyone knows of any please list them.) I believe if all of the ideas here were implemented that would give pretty good coverage of the non-woolly requirements in the incubation/graduation checklist that aren't already covered by tags or by the requirements to get into the OpenStack tent. cheers, Zane.
Re: [openstack-dev] [tc] [all] thinking additional tags
On 08/07/15 12:51, Thierry Carrez wrote: Sean Dague wrote: Personally, I'm running out of steam on tags for this cycle, but Zane brought up a good point in the TC meeting yesterday, which was that "it would be nice to have tags for criteria that we used to use for integration requirements". I strongly agree with that perspective. [...] Thanks for bringing that up. As mentioned at the TC meeting yesterday I plan to set up a small TC workgroup to aggressively look for missing tags and define them. Russell already signed up, and as all TC workgroups it can include non-TC members (it's actually a great way to do succession planning at the TC). I'm still stuck on (re)defining the release tags to match the Liberty release models, but I plan to start working on that soon after. Who is in? \o Count me in. I've been wanting to contribute to some progress in this area for a while; an organised effort will make it easier to justify the time spent to myself ;) Thanks Sean for getting the ball rolling. cheers, Zane. __ 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] [tc] [all] thinking additional tags
Sean Dague wrote: > Personally, I'm running out of steam on tags for this cycle, but Zane > brought up a good point in the TC meeting yesterday, which was that "it > would be nice to have tags for criteria that we used to use for > integration requirements". I strongly agree with that perspective. > [...] Thanks for bringing that up. As mentioned at the TC meeting yesterday I plan to set up a small TC workgroup to aggressively look for missing tags and define them. Russell already signed up, and as all TC workgroups it can include non-TC members (it's actually a great way to do succession planning at the TC). I'm still stuck on (re)defining the release tags to match the Liberty release models, but I plan to start working on that soon after. Who is in? -- Thierry Carrez (ttx) __ 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] [tc] [all] thinking additional tags
On 08/07/15 09:03, Sean Dague wrote: Personally, I'm running out of steam on tags for this cycle, but Zane brought up a good point in the TC meeting yesterday, which was that "it would be nice to have tags for criteria that we used to use for integration requirements". I strongly agree with that perspective. A few ideas I was thinking about here from the areas that I poke at quite often. I'm doing this on the ML as a lighter weight discussion medium than gerrit as these are pretty raw brain droppings. Devstack: * some tag that stated if it was in_devstack or has_devstack_plugin. I hesitate breaking those into 2, because it assumes value judgement that one is better than the other. However, has_devstack_plugin is useful information to know you need to add 1 line to your local.conf to enable that service. has_devstack_plugin has a very specific meaning that the project implements this interface - http://docs.openstack.org/developer/devstack/plugins.html +1 Equivalents for Horizon & Heat were part of the 'First cycle expectations' list, and I believe would be helpful too. I'd also like to see one for python-openstackclient and another for the SDK. We could do something similar for other projects that use plugins too, like Mistral. Ceilometer integration was also on the 'First cycle expectations' list, and would make a good tag. It also says "The lifecycle of resources managed by the project should be externalized via notifications so that they can be consumed by other integrated projects", but I'm not sure what that means... I assume those are the same notifications that Ceilometer reads? I guess it makes sense to have two tags - one for notifications being sent and one for Ceilometer knowing how to read them. Who would be responsible for applying these tags? How about it happens by joint agreement of the project receiving the tag and the relevant tag owner (e.g. Devstack for has_devstack_plugin), as represented by their respective PTLs? QA: * full_stack_testing - does the project have voting gate jobs that bring up an OpenStack environment with it and some other selection of OpenStack projects needed to test it. Basically, is the project doing more than unit testing. (Possibly also specify that tests run parallel, given that transition from serial to parallel testing has exposed real bugs in nearly every project that's done that). +1 Upgrade: There are various qualities about upgrade that we'd like to see out of projects, and highlight when they exist. * no config change upgrades - the config file for N-1 works with N * partial upgrades - N-1 and N components can exist simultaneously in a cluster (allows for rolling upgrades) * upgrade testing - changes are gated on a voting upgrade test * partial upgrade testing - changes are gated on a voting partial upgrade test +1 Most of these are pretty objective, I think there are also items around API contract, but that's actually a bit less objective, as we've seen around the debates on whether or not there is such a thing as a compatible API change with no user signaling in the microversion thread. I think we need a stable-api-since tag, but we should leave it entirely in the hands of the project teams themselves to apply. That way it's up to the project to decide when it starts enforcing API stability, and we have a clear way to communicate to users when that happened. (Previously, integrated projects were required to have stable APIs and any project not in the integrated release could be presumed not to.) Another possibility would be tags to indicate that a project uses oslo.config and oslo.log. (There may be other Oslo libraries that have a significant operator-facing interface impact, if anyone knows of any please list them.) I believe if all of the ideas here were implemented that would give pretty good coverage of the non-woolly requirements in the incubation/graduation checklist that aren't already covered by tags or by the requirements to get into the OpenStack tent. cheers, Zane. __ 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-dev] [tc] [all] thinking additional tags
Personally, I'm running out of steam on tags for this cycle, but Zane brought up a good point in the TC meeting yesterday, which was that "it would be nice to have tags for criteria that we used to use for integration requirements". I strongly agree with that perspective. A few ideas I was thinking about here from the areas that I poke at quite often. I'm doing this on the ML as a lighter weight discussion medium than gerrit as these are pretty raw brain droppings. Devstack: * some tag that stated if it was in_devstack or has_devstack_plugin. I hesitate breaking those into 2, because it assumes value judgement that one is better than the other. However, has_devstack_plugin is useful information to know you need to add 1 line to your local.conf to enable that service. has_devstack_plugin has a very specific meaning that the project implements this interface - http://docs.openstack.org/developer/devstack/plugins.html QA: * full_stack_testing - does the project have voting gate jobs that bring up an OpenStack environment with it and some other selection of OpenStack projects needed to test it. Basically, is the project doing more than unit testing. (Possibly also specify that tests run parallel, given that transition from serial to parallel testing has exposed real bugs in nearly every project that's done that). Upgrade: There are various qualities about upgrade that we'd like to see out of projects, and highlight when they exist. * no config change upgrades - the config file for N-1 works with N * partial upgrades - N-1 and N components can exist simultaneously in a cluster (allows for rolling upgrades) * upgrade testing - changes are gated on a voting upgrade test * partial upgrade testing - changes are gated on a voting partial upgrade test Most of these are pretty objective, I think there are also items around API contract, but that's actually a bit less objective, as we've seen around the debates on whether or not there is such a thing as a compatible API change with no user signaling in the microversion thread. I personally don't have near term energy to shephard any of these. However, there is no reason that tag submission needs to be done by a TC member, so if any of these bits tickle your fancy, I'd help advise on them. -Sean -- Sean Dague http://dague.net __ 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
