Open Stack

> 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

--Dan