<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 05/01/2015 09:32 AM, Fox, Kevin M wrote:<br>
<blockquote
cite="mid:1A3C52DFCD06494D8528644858247BF01A1F44EA@EX10MBOX03.pnnl.gov"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Hmm.... The cinder volumes dont automount either. /dev/vdx shows
up, but you have to format/mount it yourself.<br>
<br>
Maybe both teams could share a common solution? Im guessing it
will have to be an agent...<br>
</blockquote>
<br>
That not really true. If the volume is already formatted with a
filesystem, and the filesystem is listed in the fstab, linux will
mount it automatically. Same with Windows. Even unlabelled volumes
could be automatically formatted and mounted with some script inside
the guest that was watching for the right events.<br>
<br>
With shares, even the basic notification is not there, nor is there
a standard way for a guest to determine what mounts are available
out there (the equivalent of the existence of the /dev/* files).<br>
<br>
We'd like to solve these 2 basic problems in a way that's standard
across all Manila instances. Of course what consumes that
information and what happens afterwards would ideally be up the the
tenant, and we would like to provide a set of samples for popular
use cases.<br>
<br>
-Ben<br>
<br>
<br>
<blockquote
cite="mid:1A3C52DFCD06494D8528644858247BF01A1F44EA@EX10MBOX03.pnnl.gov"
type="cite">
Thanks,<br>
Kevin <strong>
<div><font color="#000000" face="Tahoma" size="2"> </font></div>
</strong>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> Deepak Shetty<br>
<b>Sent:</b> Thursday, April 30, 2015 9:54:31 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage
questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Manila] Mount automation
using Zeroconf<br>
</font><br>
<div>
<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>
<div class="gmail_extra"><br>
<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>
</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>