Open Stack

On Wed, Aug 3, 2016, at 02:24 PM, Chris Friesen wrote:
> On 08/03/2016 10:53 AM, Andrew Laski wrote:
> > I think the discussion about whether or not this needs a microversion is missing
> > the bigger question of whether or not this should be in the API to begin with.
> 
> I don't think it's actually in the API.

It's allowing the revert_resize API call to be used in more situations
by relaxing the vm_state checks that occur. I didn't see anything that
calls that code in the event of an error, it just leaves it open for
users to call it.

> 
> > If it's safe to rollback from this error state why not just do that
> > automatically in Nova?
> 
> I think we do for other cases, my understanding is that the issue is
> whether we 
> would need a new microversion for the API because we're changing the 
> user-visible behaviour of the migrate/resize operation when something
> goes 
> wrong.  (IE rolling back to an active state on the source rather than
> staying in 
> an ERROR state.)
> 
> > To me it seems like adding a microversion because a policy rule was
> > changed.
> 
> I believe this is exactly what it is.
> 
>  > I know we should have some sort of signal here for users, but I think
> > we need to look at different ways to signal this type of change.
> 
> How?  The microversion is (currently) the only way the client has of
> determining 
> server behaviour.

Yes, currently this is the only mechanism we have. My preference would
be to be a bit lax on signaling  while we get other mechanisms in place.
For this case I think it would make sense to wait until we have
capability exposure in the API to present a strong signal that a user
could revert from a resize with an instance in an ERROR state. In the
meantime we could use documentation and piggyback on the next
microversion to say "If you're using an API with at least version 2.x
then this capability is available." 

This is driven by my desire to avoid cruft because when we do have
capabilities exposed in the API then we're left with with this odd
microversion that signals the same thing as capabilities. I think
microversions make a lot of sense for signaling different
representations that are available in the API, e.g. an instance looks
one way at version 2.3 and looks different at 2.5. The use of a
microversion to signal something that could apply across every version
of the API makes the meaning of a microversion imprecise. I would love
to be able to explain to someone that microversions mean x. But the
reality is they have no precise definition. All they signal is
"something changed, and it may or may not be visible to you and I can't
tell you what it is, please go check the docs." /rant

> 
> Chris
> 
> __________________________________________________________________________
> 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