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: > [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
