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.kni...@netapp.com <mailto:clinton.kni...@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" <lpa...@redhat.com
<mailto:lpa...@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.kni...@netapp.com
<mailto:clinton.kni...@netapp.com>>
>To: "OpenStack Development Mailing List (not for usage questions)"
><openstack-dev@lists.openstack.org
<mailto:openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe
<http://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://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://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
__________________________________________________________________________
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
