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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
