<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 05/01/2015 12:54 AM, Deepak Shetty wrote:<br>
<blockquote
cite="mid:CAOXiiMmgBzLTVNx5ty3dMLLKTRp1aYoVmA3o2zzr2+fuQHn6hA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>Hi,<br>
</div>
Have we considered cloud-init and qemu guest agent, I
remember there was some discussion around this<br>
</div>
in the prev summit, but i couldn't find any etherpad/notes on
that.<br>
<br>
</div>
<div>I had one more question in this regards. Is it possible to
do some kind of VM hotplug add operation as part of manila<br>
</div>
<div>access allow which will cause the VM to see a new drive
with a pre-specified label and a client inside the VM will<br>
</div>
<div>mount it as part of the udev/uevent ? <br>
</div>
</div>
</blockquote>
<br>
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:<br>
* Doesn't work w/ Windows guests<br>
* Doesn't work with hypervisors other than qemu/xen<br>
* p9fs semantics are different than native nfs/cifs to the client<br>
* Some apps are coded to use NFS directly (not through the OS's
built in nfs client)<br>
* Many apps are tested/qualified with NFS/CIFS but not virtfs<br>
* Locking and FS metadata work significantly differently<br>
* VirtFS appears to be abandonware<br>
<br>
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.<br>
<br>
-Ben Swartzlander<br>
<br>
<br>
<blockquote
cite="mid:CAOXiiMmgBzLTVNx5ty3dMLLKTRp1aYoVmA3o2zzr2+fuQHn6hA@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">On Tue, Apr 28, 2015 at 11:50 PM,
Knight, Clinton <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:Clinton.Knight@netapp.com" target="_blank">Clinton.Knight@netapp.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks,
Luis, I agree with your assessment that one good way to
solve this<br>
issue is a publisher-subscriber model. The publisher would
be Manila,<br>
using zeroconf or AMQP or Zaqar (the one Iım investigating
now). The<br>
subscriber would be a lightweight agent running on the
client that listens<br>
for share availability events and handles the mounts. One
open question<br>
is whether Manila needs to store a record of client mounts,
without which<br>
it could not influence the mount paths on each client.<br>
<span class="HOEnZb"><font color="#888888"><br>
Clinton<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
<br>
On 4/27/15, 1:49 PM, "Luis Pabon" <<a
moz-do-not-send="true" href="mailto:lpabon@redhat.com">lpabon@redhat.com</a>>
wrote:<br>
<br>
>Hi Clinton,<br>
> I think there are two main parts that are needed
to automatically mount<br>
>Manila shares. One is the share discovery model,
and the other is<br>
>enabling the virtual machine to mount the share. I
think the only<br>
>benefit to using zeroconf would be as a standard way
to broadcast<br>
>availability of a network share regardless of
protocol. Manila could<br>
>broadcast the availability of a share by using a
name like _manila_nfs,<br>
>_manila_cifs, _manila_gluster, etc. Although, even
with zeroconf, the<br>
>virtual machine still requires an agent to be able
to attach the share<br>
>for use. I think the real benefit of using zeroconf
is its simplicity.<br>
><br>
>There could still be other methods we can
investigate. For example<br>
>(don't kill me for this ;-)), have a Manila YP NIS
service for NFS shares?<br>
><br>
>- Luis<br>
><br>
><br>
><br>
><br>
>----- Original Message -----<br>
>From: "Clinton Knight" <<a moz-do-not-send="true"
href="mailto:Clinton.Knight@netapp.com">Clinton.Knight@netapp.com</a>><br>
>To: "OpenStack Development Mailing List (not for
usage questions)"<br>
><<a moz-do-not-send="true"
href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>Sent: Wednesday, April 22, 2015 3:29:50 PM<br>
>Subject: [openstack-dev] [Manila] Mount automation
using Zeroconf<br>
><br>
>Hello, Manila-philes.<br>
><br>
>Back in Paris we started talking about Manila mount
automation, whereby<br>
>file shares could be automatically mounted on
clients, and this will<br>
>likely be a topic in Vancouver. So in order to have
an informed<br>
>discussion at the summit, I'd like to explore a few
things beforehand.<br>
><br>
>Besides brute force approaches like SSH or PsExec,
one of the community<br>
>suggestions was to use Zeroconf (aka Bonjour)[1].
Zeroconf sounds<br>
>attractive on the surface, but it seems to have a
number of limitations:<br>
><br>
>* No standard way to specify local mount point<br>
>* Additional setup required to work beyond the
'local' domain<br>
>* Custom software needed on clients to mount
advertised shares<br>
>* Same issues with network connectivity as any other
mount automation<br>
>solution<br>
><br>
>Does anyone have a clearer idea how Zeroconf might
satisfy the need for<br>
>Manila mount automation?<br>
><br>
>Thanks,<br>
>Clinton Knight<br>
>Manila core team<br>
><br>
>[1] <a moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/Zero-configuration_networking"
target="_blank">http://en.wikipedia.org/wiki/Zero-configuration_networking</a><br>
><br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage
questions)<br>
>Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage
questions)<br>
>Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>