Open Stack

On 11/17/2015 10:02 AM, John Spray wrote:
> Hi all,
>
> As you may know, there is ongoing work on a spec for Nova to define an
> "attach/detach" API for tighter integration with Manila.
>
> The concept here is that this mechanism will be needed to implement
> hypervisor mediated FS access using vsock, but that the mechanism
> should also be applicable more generally to an "attach" concept for
> filesystems accessed over IP networks (like existing NFS filers).
>
> In the hypervisor-mediated case, attach would involve the hypervisor
> host connecting as a filesystem client and then re-exporting to the
> guest via a local address.  We think this would apply to
> driver_handles_share_servers type drivers that support share networks,
> by mapping the attach/detach share API to attaching/detaching the
> share network from the guest VM.
>
> Does that make sense to people maintaining this type of driver?  For
> example, for the netapp and generic drivers, is it reasonable to
> expose nova attach/detach APIs that attach and detach the associated
> share network?

I'm not sure this proposal makes sense. I would like the share 
attach/detach semantics to be the same for all types of shares, 
regardless of the driver type.

The main challenge with attaching to shares on share servers (with share 
networks) is that there may not exist a network route from the 
hypervisor to the share server, because share servers are only required 
to be accessible from the share network from which they are created. 
This has been a known problem since Liberty because this behaviour 
prevents migration from working, therefore we're proposing a mechanism 
for share-server drivers to provide admin-network-facing interfaces for 
all share servers. This same mechanism should be usable by the Nova when 
doing share attach/detach. Nova would just need to list the export 
locations using an admin-context to see the admin-facing export location 
that it should use.

> I've CC'd Luis who is working on the Nova spec.
>
> Regards,
> John
>
> __________________________________________________________________________
> 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
>