<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 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 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 href="mailto:Clinton.Knight@netapp.com">Clinton.Knight@netapp.com</a>><br>
>To: "OpenStack Development Mailing List (not for usage questions)"<br>
><<a 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 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 href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a 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 href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a 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 href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a 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>