Re: [openstack-dev] [Manila] Mount automation using Zeroconf
Same is true of network shares. If its already listed in fstab, it will just work. But an admin's got to manually add it there. My point is automation is not supported in cinder either? Thanks, Kevin From: Ben Swartzlander [b...@swartzlander.org] Sent: Friday, May 01, 2015 8:19 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Manila] Mount automation using Zeroconf On 05/01/2015 09:32 AM, Fox, Kevin M wrote: Hmm The cinder volumes dont automount either. /dev/vdx shows up, but you have to format/mount it yourself. Maybe both teams could share a common solution? Im guessing it will have to be an agent... 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. 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). 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. -Ben Thanks, Kevin From: Deepak Shetty Sent: Thursday, April 30, 2015 9:54:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Manila] Mount automation using Zeroconf 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 ? On Tue, Apr 28, 2015 at 11:50 PM, Knight, Clinton clinton.kni...@netapp.commailto: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.commailto: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.commailto:clinton.kni...@netapp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: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
Re: [openstack-dev] [Manila] Mount automation using Zeroconf
On 05/01/2015 09:32 AM, Fox, Kevin M wrote: Hmm The cinder volumes dont automount either. /dev/vdx shows up, but you have to format/mount it yourself. Maybe both teams could share a common solution? Im guessing it will have to be an agent... 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. 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). 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. -Ben Thanks, Kevin * * *From:* Deepak Shetty *Sent:* Thursday, April 30, 2015 9:54:31 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Manila] Mount automation using Zeroconf 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 ? 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
Re: [openstack-dev] [Manila] Mount automation using Zeroconf
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
Re: [openstack-dev] [Manila] Mount automation using Zeroconf
Hmm The cinder volumes dont automount either. /dev/vdx shows up, but you have to format/mount it yourself. Maybe both teams could share a common solution? Im guessing it will have to be an agent... Thanks, Kevin From: Deepak Shetty Sent: Thursday, April 30, 2015 9:54:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Manila] Mount automation using Zeroconf 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 ? On Tue, Apr 28, 2015 at 11:50 PM, Knight, Clinton clinton.kni...@netapp.commailto: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.commailto: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.commailto:clinton.kni...@netapp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: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:unsubscribehttp://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:unsubscribehttp://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:unsubscribehttp://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
Re: [openstack-dev] [Manila] Mount automation using Zeroconf
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 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 To: OpenStack Development Mailing List (not for usage questions) 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://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
Re: [openstack-dev] [Manila] Mount automation using Zeroconf
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 To: OpenStack Development Mailing List (not for usage questions) 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://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-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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
