On Wed, Oct 04, 2017 at 02:07:53PM +0100, Jean-Philippe Evrard wrote: > > - 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.
That's a good point. I think for Nova and Cinder (the only two being looked at so far), there aren't any special steps to achieve this. Other than not rebooting the host instead of just restarting services. If a project does need extra precautions taken, then I agree that should be part of this that it is documented somewhere. Would you like to add some text stating that to the Requirements section? [1] [1] https://git.openstack.org/cgit/openstack/governance/tree/reference/tags/assert_supports-accessible-upgrade.rst > > 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? > Another good question! There is some discussion going on right now on whether any of these tags really apply to deployment projects. I think service projects were really what was in mind when they were created, whether intentionally or not. Applying it to mean that accessible projects are deployed accessibly by a deployment tool kind of makes sense, but I would be concerned we would hit some situation where it doesn't quite fit like we have with the stable policy tag. I think that needs more discussion for sure. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
