On Tue, Oct 3, 2017 at 7:52 PM, Sean McGinnis <sean.mcgin...@gmx.com> wrote: > I'm hoping this will get a little more attention. > > We recently started discussing removing governance tags that did not have any > projects asserting them. I think this makes a lot of sense. Some tags were > defined apparently in the hope that it would get projects thinking about them > and wanting to either apply for the tag, or do the work to be able to meet the > requirements for that tag. > > While this may have worked in some cases, we do have a few that are a little > unclear and not really getting much attention. We will likely clean up that > tag list a little, but there was some push back on at least one tag. > > The supports-accessible-upgrade tag basically states that a service can be > upgraded without affecting access to the resources that the service manages > [1]. This actually fits with how at least Nova and Cinder work, so a patch is > now out there to assert this for those two projects [2]. > > I would bet there are several other projects out there that work in this same > way. Since we are looking between removing tags or using them (use it or lose > it), I would actually love to see more projects asserting this tag. If your > project manages a set of resources that are available even when your service > is down and/or being upgraded, please consider submitting a patch like [2] to > add your project to the list. > > And just a general call out to raise awareness - please take a look through > the other defined tags and see if there are any others that are applicable to > your projects [3]. > > Thanks! > > Sean (smcginnis) > > > [1] > https://governance.openstack.org/tc/reference/tags/assert_supports-accessible-upgrade.html > [2] https://review.openstack.org/#/c/509170/ > [3] https://governance.openstack.org/tc/reference/tags/index.html > > __________________________________________________________________________ > 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
Hello, I like the idea. A few comments, I don't know if it's too late for that, but I shoot anyway: - I don't see any mention of documentation in the required steps to get this governance tag. I think it can serve the community better if we enforce the inclusion of the documentation on 'HOW to trigger this "accessible" upgrade'. What do you think? - As part of a deployment project team, I like the fact it's easy for us (and for our users) to see which service is behaving "accessibly". It sets expectations, both for us and for the deployers. I have questions on that "expectations" part: Would you like the deployment projects apply for those tags? How do you see that going? What are the requirements we have to match for a deployment project to be considered "upgrade accessible" ? In my opinion it should be something along the lines of: "if an upstream "accessible" project is deployed, it should be upgraded in an "accessible" way, while non "accessible" projects would fallback to a standard 'supporting upgrade' pattern?" Or alternatively, we don't apply this tag to deployment projects. Opinion? __________________________________________________________________________ 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