Open Stack

On 05/01/2015 12:54 AM, Deepak Shetty wrote:
> Hi,
>   Have we considered cloud-init and qemu guest agent, I remember there 
> was some discussion around this
> in the prev summit, but i couldn't find any etherpad/notes on that.
>
> I had one more question in this regards. Is it possible to do some 
> kind of VM hotplug add operation as part of manila
> access allow which will cause the VM to see a new drive with a 
> pre-specified label and a client inside the VM will
> mount it as part of the udev/uevent ?

The only way to get hotplug working for shares (that I know of) would be 
to use virtfs. In that case the hypervisor would mount the share and 
present it to the guest through a p9fs/virtio tunnel. This would be 
pretty cool but also has a bunch of disadvantages:
* Doesn't work w/ Windows guests
* Doesn't work with hypervisors other than qemu/xen
* p9fs semantics are different than native nfs/cifs to the client
    * Some apps are coded to use NFS directly (not through the OS's 
built in nfs client)
    * Many apps are tested/qualified with NFS/CIFS but not virtfs
    * Locking and FS metadata work significantly differently
* VirtFS appears to be abandonware

If anyone knows of a way other than VirtFS to get cool hotplug 
semantics, I'd love to know. Also, if any of my above assertions are 
false, I'd also love to know about that too.

-Ben Swartzlander


> On Tue, Apr 28, 2015 at 11:50 PM, Knight, Clinton 
> <Clinton.Knight at netapp.com <mailto:Clinton.Knight at netapp.com>> wrote:
>
>     Thanks, Luis, I agree with your assessment that one good way to
>     solve this
>     issue is a publisher-subscriber model.  The publisher would be Manila,
>     using zeroconf or AMQP or Zaqar (the one I¹m investigating now).  The
>     subscriber would be a lightweight agent running on the client that
>     listens
>     for share availability events and handles the mounts.  One open
>     question
>     is whether Manila needs to store a record of client mounts,
>     without which
>     it could not influence the mount paths on each client.
>
>     Clinton
>
>
>     On 4/27/15, 1:49 PM, "Luis Pabon" <lpabon at redhat.com
>     <mailto:lpabon at redhat.com>> wrote:
>
>     >Hi Clinton,
>     >  I think there are two main parts that are needed to
>     automatically mount
>     >Manila shares.  One is the share discovery model, and the other is
>     >enabling the virtual machine to mount the share.  I think the only
>     >benefit to using zeroconf would be as a standard way to broadcast
>     >availability of a network share regardless of protocol.  Manila could
>     >broadcast the availability of a share by using a name like
>     _manila_nfs,
>     >_manila_cifs, _manila_gluster, etc.  Although, even with
>     zeroconf, the
>     >virtual machine still requires an agent to be able to attach the
>     share
>     >for use.  I think the real benefit of using zeroconf is its
>     simplicity.
>     >
>     >There could still be other methods we can investigate.  For example
>     >(don't kill me for this ;-)), have a Manila YP NIS service for
>     NFS shares?
>     >
>     >- Luis
>     >
>     >
>     >
>     >
>     >----- Original Message -----
>     >From: "Clinton Knight" <Clinton.Knight at netapp.com
>     <mailto:Clinton.Knight at netapp.com>>
>     >To: "OpenStack Development Mailing List (not for usage questions)"
>     ><openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>>
>     >Sent: Wednesday, April 22, 2015 3:29:50 PM
>     >Subject: [openstack-dev] [Manila] Mount automation using Zeroconf
>     >
>     >Hello, Manila-philes.
>     >
>     >Back in Paris we started talking about Manila mount automation,
>     whereby
>     >file shares could be automatically mounted on clients, and this will
>     >likely be a topic in Vancouver. So in order to have an informed
>     >discussion at the summit, I'd like to explore a few things
>     beforehand.
>     >
>     >Besides brute force approaches like SSH or PsExec, one of the
>     community
>     >suggestions was to use Zeroconf (aka Bonjour)[1]. Zeroconf sounds
>     >attractive on the surface, but it seems to have a number of
>     limitations:
>     >
>     >* No standard way to specify local mount point
>     >* Additional setup required to work beyond the 'local' domain
>     >* Custom software needed on clients to mount advertised shares
>     >* Same issues with network connectivity as any other mount automation
>     >solution
>     >
>     >Does anyone have a clearer idea how Zeroconf might satisfy the
>     need for
>     >Manila mount automation?
>     >
>     >Thanks,
>     >Clinton Knight
>     >Manila core team
>     >
>     >[1] http://en.wikipedia.org/wiki/Zero-configuration_networking
>     >
>     >
>     >__________________________________________________________________________
>     >OpenStack Development Mailing List (not for usage questions)
>     >Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150501/5c4d2226/attachment.html>