Open Stack

On 11/18/2015 05:31 AM, John Spray wrote:
> On Wed, Nov 18, 2015 at 4:33 AM, Ben Swartzlander <ben at swartzlander.org> wrote:
>> 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.
>
> For these drivers, we're not proposing connecting to them from the
> hypervisor -- we would still be connecting directly from the guest via
> the share network.
>
> The change would be from the existing workflow:
>   * Create share
>   * Attach guest network to guest VM (need to look up network info,
> talk to neutron API)

I think this is the point of confusion. The design for share-networks in 
Manila is to re-use your existing networks. A VM with no network 
connection is not particularly useful -- we assume that all VMs have at 
least 1 private network. The idea behind the share network is to map 
shares onto that private network so that the above step in unnecessary.

It's true that if you have _no_ network at all or if you have a 
particularly complicated network configuration, you may need to do an 
additional network attachment to access Manila shares. That should be an 
exceptional case though, no the norm.

>   * Add IP access permission for the guest to access the share (need to
> know IP of the guest)

If the guest has a private network and it's mapped to the share network, 
then the access only needs to be granted to the private IP. I agree it 
would be nicer to grant access by instance ID rather than IP, but in 
reality that mapping can be performed automatically and cheaply.

>   * Mount from guest VM
>
> To a new workflow:
>   * Create share
>   * Attach share to guest (knowing only share ID and guest instance ID)
>   * Mount from guest VM
>
> The idea is to abstract the networking part away, so that the user
> just has to say "I want to be able to mount share X from guest Y",
> without knowing about the networking stuff going on under the hood.
> While this is partly because it's slicker, this is mainly so that
> applications can use IP-networking shares interchangeably with future
> hypervisor mediated shares: they call "attach" and don't have to worry
> about whether that's a share network operation under the hood or a
> hypervisor-twiddling operation under the hood.

I think we are already closer than you think. In most cases the only 
missing automation is knowing how to turn an instance ID into an IP 
address to give to Manila's access-allow API. There are 2 potential 
solutions to that problem:

1) Add and API to Manila or a layer on top of Manila that gives 
grant-access-by-instance-ID semantics.

2) Do the nova attach implementation and always use the hypervisor IP 
instead of the guest IP when talking to Manila.

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