Open Stack

On Tue, Oct 3, 2017 at 7:52 PM, Sean McGinnis <sean.mcginnis at 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-request at 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?