Open Stack

On Wed, Jan 13, 2016, at 07:25 PM, Dan Smith wrote:
> > While I don't think it's strictly required by the api change guidelines [3]
> > I think the API interactions and behavior here feel different enough to warrant
> > having a microversion. Ideally there should have been some versioning in the
> > cinder api around the multiattach support but that ship has already sailed.
> > Treating the volume attach case in nova as the traditional single attach case
> > by default and having to specify a new microversion to enable using multiple
> > attach will at least make it more explicit to users which I think is a good
> > thing.
> 
> Right, I think the client explicitly saying "I know that there is this
> new thing called multi-attach" or "I should know but I didn't read the
> docs and irresponsibly claim to support this version anyway" is an
> important thing to have. While it doesn't (AFAIK) fall under the
> guidelines for signalling a change as you say, it is a big change
> regardless. There could certainly be clients that have the same
> attachment assumptions as nova currently has.
> 
> The problem is that we can't honor the pre-microversion semantics to
> older clients. Meaning, a client that claims to know nothing about
> multi-attach is going to make the assumptions it was making anyway, and
> we can't un-ring the bell for that client.
> 
> Still, I think it's useful to signal this change if for no other reason
> than it will hopefully catch the attention of careful client authors as
> they bump their maximum supported version declaration.
> 
> > I'm probably overlooking something major but shouldn't nova know if the virt
> > driver supports multiattach? If there are no computes with a compatible setup
> > why not just return an error and not even attempt the cast? I'm guessing all the
> > necessary info isn't in the DB which means there isn't a way to check this up
> > front.
> 
> We don't have that information, and as you hint above, we can have
> multiple virt drivers with varying levels of support in a single
> deployment. However, the inevitable result of "No Valid Host" is a
> little more correct in the case of the virt driver support situation.
> You asked us to do a thing, which was reasonable and supported by nova
> but ... during scheduling we failed to find any computes willing to
> honor the request. That could have been different ten minutes ago, and
> could certainly be different an hour from now. That fits NoValidHost
> properly I think.
> 
> If you've been told by cinder that your volume supports multi-attach,
> and nova is new enough to claim it supports it, returning 400 seems
> unfair and confusing to the user -- the operation should be valid.
> 
> So in summary:
> 
> - I think a microversion is not specifically required, but useful
> - I think a config or dynamic flag to change the API behavior is wrong
> - NoValidHost when no available hypervisors support it seems appropriate

I think NoValidHost is appropriate for now as well.

It is however not ideal when a deployment is set up such that
multiattach will always fail because a hypervisor is in use which
doesn't support it.  An immediate solution would be to add a policy so a
deployer could disallow it that way which would provide immediate
feedback to a user that they can't do it.  A longer term solution would
be to add capabilities to flavors and have flavors act as a proxy
between the user and various hypervisor capabilities available in the
deployment.  Or we can focus on providing better async feedback through
instance-actions, and other discussed async api changes.



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