Re: [openstack-dev] [ptl][tc] Accessible upgrade support

[Kevin Benton]

Oh, I suppose it depends on what you mean by "ovs" in this context. The
Neutron OVS agent shouldn't trigger any flow losses, but restarted the OVS
vswitchd process may do that.

On Sat, Oct 7, 2017 at 2:31 AM, Sean Dague  wrote:

> On 10/06/2017 07:23 PM, Kevin Benton wrote:
>
>>  >The neutron story is mixed on accessable upgrade, because at least in
>> some cases, like ovs, upgrade might trigger a network tear down / rebuild
>> that generates an outage (though typically a pretty small one).
>>
>> This shouldn't happen. If it does it should be reported as a bug. All
>> existing OVS flows are left in place during agent initialization and we
>> don't get rid of the old ones until the agent finishes setting up the new
>> ones.
>>
>
> I thought it was literally a problem with the daemon restart where it is
> stateful and does a teardown / rebuild when started. I'd be happy to be
> wrong about that, but was told in the past that it was just an OVS
> limitation.
>
>
> -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
>
__
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] [ptl][tc] Accessible upgrade support

[Sean Dague]

On 10/06/2017 07:23 PM, Kevin Benton wrote:
 >The neutron story is mixed on accessable upgrade, because at least in 
some cases, like ovs, upgrade might trigger a network tear down / 
rebuild that generates an outage (though typically a pretty small one).


This shouldn't happen. If it does it should be reported as a bug. All 
existing OVS flows are left in place during agent initialization and we 
don't get rid of the old ones until the agent finishes setting up the 
new ones.


I thought it was literally a problem with the daemon restart where it is 
stateful and does a teardown / rebuild when started. I'd be happy to be 
wrong about that, but was told in the past that it was just an OVS 
limitation.


-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] [ptl][tc] Accessible upgrade support

[Kevin Benton]

>The neutron story is mixed on accessable upgrade, because at least in some
cases, like ovs, upgrade might trigger a network tear down / rebuild that
generates an outage (though typically a pretty small one).

This shouldn't happen. If it does it should be reported as a bug. All
existing OVS flows are left in place during agent initialization and we
don't get rid of the old ones until the agent finishes setting up the new
ones.

On Thu, Oct 5, 2017 at 4:42 AM, Sean Dague  wrote:

> On 10/05/2017 07:08 AM, Graham Hayes wrote:
> >
> >
> > On Thu, 5 Oct 2017, at 09:50, Thierry Carrez wrote:
> >> Matt Riedemann wrote:
> >>> What's the difference between this tag and the zero-impact-upgrades
> tag?
> >>> I guess the accessible one is, can a user still ssh into their VM while
> >>> the nova compute service is being upgraded. The zero-impact-upgrade one
> >>> is more to do with performance degradation during an upgrade. I'm not
> >>> entirely sure what that might look like, probably need operator input.
> >>> For example, while upgrading, you're live migrating VMs all over the
> >>> place which is putting extra strain on the network.
> >>
> >> The zero-impact-upgrade tag means no API downtime and no measurable
> >> impact on performance, while the accessible-upgrade means that while
> >> there can be API downtime, the resources provisioned are still
> >> accessible (you can use the VM even if nova-api is down).
> >>
> >> I still think we have too many of those upgrade tags, and amount of
> >> information they provide does not compensate the confusion they create.
> >> If you're not clear on what they mean, imagine a new user looking at the
> >> Software Navigator...
> >>
> >> In particular, we created two paths in the graph:
> >> * upgrade < accessible-upgrade
> >> * upgrade < rolling-upgrade < zero-downtime < zero-impact
> >>
> >> I personally would get rid of zero-impact (not sure there is that much
> >> additional information it conveys beyond zero-downtime).
> >>
> >> If we could make the requirements of accessible-upgrade a part of
> >> rolling-upgrade, that would also help (single path in the graph, only 3
> >> "levels"). Is there any of the current rolling-upgrade things (cinder,
> >> neutron, nova, swift) that would not qualify for accessible-upgrade as
> >> well ?
> >
> > Well, there is projects (like designate) that qualify for accessible
> > upgrade, but not rolling upgrade.
>
> The neutron story is mixed on accessable upgrade, because at least in
> some cases, like ovs, upgrade might trigger a network tear down /
> rebuild that generates an outage (though typically a pretty small one).
>
> I still think it's hard to describe to folks what is going on without
> pictures. And the tag structure might just be the wrong way to describe
> the world, because they are a set of positive assertions, and upgrade
> expectations are really about: "how terrible will this be".
>
> If I was an operator the questions I might have is:
>
> 1) Really basic, will my db roll forward?
>
> 2) When my db rolls forward, is it going to take a giant table lock that
> is effectively an outage?
>
> 3) Is whatever date I created, computes, networks going to stay up when
> I do all this? (i.e. no customer workload interuption)
>
> 4) If the service is more than 1 process, can they arbitrarily work with
> N-1 so I won't have a closet outage when services restart.
>
> 5) If the service runs on more than 1 host, can I mix host levels, or
> will there be an outage as I upgrade nodes
>
> 6) If the service talks to other openstack services, is there a strict
> version lock in which means I've got to coordinate with those for
> upgrade? If so, what order is that and is it clear?
>
> 7) Can I seamlessly hide my API upgrade behind HA-Proxy / Istio / (or
> similar) so that there is no API service interruption
>
> 8) Is there any substantial degradation in running "mixed mode" even if
> it's supported, so that I know whether I can do this over a longer
> window of time when time permits
>
> 9) What level of validation exists to ensure that any of these "should
> work" do work?
>
>
> The tags were really built around grouping a few of these, but even with
> folks that are near the problem, they got confusing quick. I really
> think that some more pictoral upgrade safety cards or something
> explaining the things you need to consider, and what parts projects
> handle for you would be really useful. And then revisit whatever the
> tagging structure is going to be later.
>
>
> -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
>
__
OpenStack Development Mailing List (not for 

Re: [openstack-dev] [ptl][tc] Accessible upgrade support

[Thierry Carrez]

Sean Dague wrote:
> [...]
> I still think it's hard to describe to folks what is going on without
> pictures. And the tag structure might just be the wrong way to describe
> the world, because they are a set of positive assertions, and upgrade
> expectations are really about: "how terrible will this be".
> 
> If I was an operator the questions I might have is:
> [...]
> 
> The tags were really built around grouping a few of these, but even with
> folks that are near the problem, they got confusing quick. I really
> think that some more pictoral upgrade safety cards or something
> explaining the things you need to consider, and what parts projects
> handle for you would be really useful. And then revisit whatever the
> tagging structure is going to be later.

Good point. Maybe the upgrade functionality is critical enough to
warrant its own data set, and using a set of binary tags is not the best
way to capture it.

-- 
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] [ptl][tc] Accessible upgrade support

[Thierry Carrez]

Graham Hayes wrote:
> On Thu, 5 Oct 2017, at 09:50, Thierry Carrez wrote:
>> [...]
>> In particular, we created two paths in the graph:
>> * upgrade < accessible-upgrade
>> * upgrade < rolling-upgrade < zero-downtime < zero-impact
>>
>> I personally would get rid of zero-impact (not sure there is that much
>> additional information it conveys beyond zero-downtime).
>>
>> If we could make the requirements of accessible-upgrade a part of
>> rolling-upgrade, that would also help (single path in the graph, only 3
>> "levels"). Is there any of the current rolling-upgrade things (cinder,
>> neutron, nova, swift) that would not qualify for accessible-upgrade as
>> well ?
> 
> Well, there is projects (like designate) that qualify for accessible
> upgrade, but not rolling upgrade.

Sure, but is there real user value in communicating that capability
separately from the rolling-upgrade ability ? And if there is value, is
it enough to justify creating a harder-to-decipher upgrade tag landscape ?

The fact that you didn't apply for the tag yet points to the limited
value of it...

-- 
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] [ptl][tc] Accessible upgrade support

[Sean Dague]

On 10/05/2017 07:08 AM, Graham Hayes wrote:
> 
> 
> On Thu, 5 Oct 2017, at 09:50, Thierry Carrez wrote:
>> Matt Riedemann wrote:
>>> What's the difference between this tag and the zero-impact-upgrades tag?
>>> I guess the accessible one is, can a user still ssh into their VM while
>>> the nova compute service is being upgraded. The zero-impact-upgrade one
>>> is more to do with performance degradation during an upgrade. I'm not
>>> entirely sure what that might look like, probably need operator input.
>>> For example, while upgrading, you're live migrating VMs all over the
>>> place which is putting extra strain on the network.
>>
>> The zero-impact-upgrade tag means no API downtime and no measurable
>> impact on performance, while the accessible-upgrade means that while
>> there can be API downtime, the resources provisioned are still
>> accessible (you can use the VM even if nova-api is down).
>>
>> I still think we have too many of those upgrade tags, and amount of
>> information they provide does not compensate the confusion they create.
>> If you're not clear on what they mean, imagine a new user looking at the
>> Software Navigator...
>>
>> In particular, we created two paths in the graph:
>> * upgrade < accessible-upgrade
>> * upgrade < rolling-upgrade < zero-downtime < zero-impact
>>
>> I personally would get rid of zero-impact (not sure there is that much
>> additional information it conveys beyond zero-downtime).
>>
>> If we could make the requirements of accessible-upgrade a part of
>> rolling-upgrade, that would also help (single path in the graph, only 3
>> "levels"). Is there any of the current rolling-upgrade things (cinder,
>> neutron, nova, swift) that would not qualify for accessible-upgrade as
>> well ?
> 
> Well, there is projects (like designate) that qualify for accessible
> upgrade, but not rolling upgrade.

The neutron story is mixed on accessable upgrade, because at least in
some cases, like ovs, upgrade might trigger a network tear down /
rebuild that generates an outage (though typically a pretty small one).

I still think it's hard to describe to folks what is going on without
pictures. And the tag structure might just be the wrong way to describe
the world, because they are a set of positive assertions, and upgrade
expectations are really about: "how terrible will this be".

If I was an operator the questions I might have is:

1) Really basic, will my db roll forward?

2) When my db rolls forward, is it going to take a giant table lock that
is effectively an outage?

3) Is whatever date I created, computes, networks going to stay up when
I do all this? (i.e. no customer workload interuption)

4) If the service is more than 1 process, can they arbitrarily work with
N-1 so I won't have a closet outage when services restart.

5) If the service runs on more than 1 host, can I mix host levels, or
will there be an outage as I upgrade nodes

6) If the service talks to other openstack services, is there a strict
version lock in which means I've got to coordinate with those for
upgrade? If so, what order is that and is it clear?

7) Can I seamlessly hide my API upgrade behind HA-Proxy / Istio / (or
similar) so that there is no API service interruption

8) Is there any substantial degradation in running "mixed mode" even if
it's supported, so that I know whether I can do this over a longer
window of time when time permits

9) What level of validation exists to ensure that any of these "should
work" do work?


The tags were really built around grouping a few of these, but even with
folks that are near the problem, they got confusing quick. I really
think that some more pictoral upgrade safety cards or something
explaining the things you need to consider, and what parts projects
handle for you would be really useful. And then revisit whatever the
tagging structure is going to be later.


-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] [ptl][tc] Accessible upgrade support

[Graham Hayes]

On Thu, 5 Oct 2017, at 09:50, Thierry Carrez wrote:
> Matt Riedemann wrote:
> > What's the difference between this tag and the zero-impact-upgrades tag?
> > I guess the accessible one is, can a user still ssh into their VM while
> > the nova compute service is being upgraded. The zero-impact-upgrade one
> > is more to do with performance degradation during an upgrade. I'm not
> > entirely sure what that might look like, probably need operator input.
> > For example, while upgrading, you're live migrating VMs all over the
> > place which is putting extra strain on the network.
> 
> The zero-impact-upgrade tag means no API downtime and no measurable
> impact on performance, while the accessible-upgrade means that while
> there can be API downtime, the resources provisioned are still
> accessible (you can use the VM even if nova-api is down).
> 
> I still think we have too many of those upgrade tags, and amount of
> information they provide does not compensate the confusion they create.
> If you're not clear on what they mean, imagine a new user looking at the
> Software Navigator...
> 
> In particular, we created two paths in the graph:
> * upgrade < accessible-upgrade
> * upgrade < rolling-upgrade < zero-downtime < zero-impact
> 
> I personally would get rid of zero-impact (not sure there is that much
> additional information it conveys beyond zero-downtime).
> 
> If we could make the requirements of accessible-upgrade a part of
> rolling-upgrade, that would also help (single path in the graph, only 3
> "levels"). Is there any of the current rolling-upgrade things (cinder,
> neutron, nova, swift) that would not qualify for accessible-upgrade as
> well ?

Well, there is projects (like designate) that qualify for accessible
upgrade, but not rolling upgrade.

> 
> -- 
> 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] [ptl][tc] Accessible upgrade support

[Thierry Carrez]

Matt Riedemann wrote:
> What's the difference between this tag and the zero-impact-upgrades tag?
> I guess the accessible one is, can a user still ssh into their VM while
> the nova compute service is being upgraded. The zero-impact-upgrade one
> is more to do with performance degradation during an upgrade. I'm not
> entirely sure what that might look like, probably need operator input.
> For example, while upgrading, you're live migrating VMs all over the
> place which is putting extra strain on the network.

The zero-impact-upgrade tag means no API downtime and no measurable
impact on performance, while the accessible-upgrade means that while
there can be API downtime, the resources provisioned are still
accessible (you can use the VM even if nova-api is down).

I still think we have too many of those upgrade tags, and amount of
information they provide does not compensate the confusion they create.
If you're not clear on what they mean, imagine a new user looking at the
Software Navigator...

In particular, we created two paths in the graph:
* upgrade < accessible-upgrade
* upgrade < rolling-upgrade < zero-downtime < zero-impact

I personally would get rid of zero-impact (not sure there is that much
additional information it conveys beyond zero-downtime).

If we could make the requirements of accessible-upgrade a part of
rolling-upgrade, that would also help (single path in the graph, only 3
"levels"). Is there any of the current rolling-upgrade things (cinder,
neutron, nova, swift) that would not qualify for accessible-upgrade as
well ?

-- 
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] [ptl][tc] Accessible upgrade support

[Jimmy McArthur]

Matt Riedemann 
October 4, 2017 at 10:51 AM


What's the difference between this tag and the zero-impact-upgrades 
tag? I guess the accessible one is, can a user still ssh into their VM 
while the nova compute service is being upgraded. The 
zero-impact-upgrade one is more to do with performance degradation 
during an upgrade. I'm not entirely sure what that might look like, 
probably need operator input. For example, while upgrading, you're 
live migrating VMs all over the place which is putting extra strain on 
the network.


I think all of the tags could benefit from some examples for real use 
cases so people have context when reading them.
We do provide tag definitions. They're linked from the Project Navigator 
(e.g. 
https://docs.openstack.org/project-team-guide/stable-branches.html). 
These provide pretty thorough definitions, and in some cases examples. I 
like the idea of having additional examples per project and that's 
something we could easily put into the Project Navigator.


Also, does the Foundation have any data on how much tags are used as 
input to weigh decisions about choosing to adopt an OpenStack project 
in a deployment or not?
One could probably make this inference based around user survey data + 
which tags are used in the more vs. less popular projects. Right now, 
it's not something we track, but it's an interesting point. I'll spend 
some time looking at it :)
I'm not entirely sure what the carrot and stick is with tags or if/how 
people are consuming them. I don't ever think about tags personally, 
probably because there is no bi-annual audit process on them to see if 
we need to add/remove tags from nova.
It's a good point. So far the biggest carrot is to make sure your 
project stats look as up to date as other mature and well adopted 
projects. To date, it seems to have had a positive impact in getting 
projects to keep their tags updated and/or figure out what they need to 
do to get the tag.


Sean McGinnis 
October 3, 2017 at 1:52 PM
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


__
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] [ptl][tc] Accessible upgrade support

[Matt Riedemann]

On 10/3/2017 1:52 PM, Sean McGinnis 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



What's the difference between this tag and the zero-impact-upgrades tag? 
I guess the accessible one is, can a user still ssh into their VM while 
the nova compute service is being upgraded. The zero-impact-upgrade one 
is more to do with performance degradation during an upgrade. I'm not 
entirely sure what that might look like, probably need operator input. 
For example, while upgrading, you're live migrating VMs all over the 
place which is putting extra strain on the network.


I think all of the tags could benefit from some examples for real use 
cases so people have context when reading them.


Also, does the Foundation have any data on how much tags are used as 
input to weigh decisions about choosing to adopt an OpenStack project in 
a deployment or not? I'm not entirely sure what the carrot and stick is 
with tags or if/how people are consuming them. I don't ever think about 
tags personally, probably because there is no bi-annual audit process on 
them to see if we need to add/remove tags from nova.


--

Thanks,

Matt

__
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] [ptl][tc] Accessible upgrade support

[Sean McGinnis]

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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptl][tc] Accessible upgrade support

[Jean-Philippe Evrard]

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

[openstack-dev] [ptl][tc] Accessible upgrade support

[Sean McGinnis]

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