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: > [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
