Open Stack

Hi All,

I wonder whether we could provide an interface on the API where these kind of capabilities can be retrieved? I know we have a support matrix in the documentation that's good to have. I asked the question, because here we have a base functionality, which is attaching a volume that Cinder exports. The multiattach feature is an extension to this, which is provided by Cinder and we wire it into Nova to provide this functionality for the instances. It's not a question that the API behavior will change by this, but it's more the matter of the components that allows the multiple attachments. In this sense the API microversion does not provide too much information standalone, it can only say that if you have all the good drivers set up in your environment, then you can use it. But do we have a way to check this?

Also in order to be able to introduce multiattach in the N cycle there are two patches that we have to land for Mitaka [1] [2]. [1] prepares the detach mechanism to send all the information to Cinder in order to identify the right attachment. This means to pass the attachment_id to Cinder. In case of an upgrade when we can have old and new components in the system it is important that if a new component attaches a volume for the second time then the detach called on the old one can be executed properly. [2] is need for Cinder as some of the drivers need the host information for tracking the attachments of the same volume on the same host properly.

> -----Original Message-----
> From: Matt Riedemann [mailto:mriedem at linux.vnet.ibm.com]
> Sent: January 14, 2016 17:11
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova][cinder] How will nova advertise that volume multi-attach is supported?
> 
> 
> 
> On 1/14/2016 9:42 AM, Dan Smith wrote:
> >> 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.
> >
> > Presumably a deployer doesn't enable volumes to be set as multi-attach
> > on the cinder side if their nova doesn't support it at all, right? I
> > would expect that is the gating policy element for something global.
> 
> There is no policy in cinder to disallow creating multiattach-able volumes [1]. It's just a property on the volume and somewhere in
> cinder the volume drivers support the capability or not.
> 
>  From a very quick look at the cinder code, the scheduler has a capabilities filter for multiattach so if you try to create a multiattach
> volume and don't have any hosts (volume backends) that support that, you'd fail to create the volume with NoValidHost.
> 
> But lvm supports it, so if you have an lvm backend you can create the multiattach volume, that doesn't mean you can use it in nova. So
> it seems like you'd also need the same kind of capabilities filter in the nova scheduler for this and that capability from the compute
> host would come from the virt driver, of which only libvirt is going to support it at first.

Do I understand correctly that you mean that we would specify at VM creation time that it should go to a compute host where the hypervisor supports multiattach?

Thanks,
/Ildikó

[1] https://review.openstack.org/#/c/193134/ 
[2] https://review.openstack.org/#/c/256273/ 

> 
> >
> > Now, if multiple novas share a common cinder, then I guess it gets a
> > little more confusing...
> >
> > --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
> >
> 
> [1]
> https://github.com/openstack/cinder/blob/master/cinder/api/v2/volumes.py#L407
> 
> --
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __________________________________________________________________________
> 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