Open Stack

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)