Hi Valeriy, thanks for feedback. My answers see below.
Am 02.12.2014 um 16:44 schrieb Valeriy Ponomaryov <vponomar...@mirantis.com>: > Hello Marc, > > Here, I tried to cover mentioned use cases with "implemented or not" notes: > > 1) Implemented, but details of implementation are different for different > share drivers. > 2) Not clear for me. If you mean possibility to mount one share to any amount > of VMs, then yes. That means you have an existing shared volume in your storage system and import it to manila (like cinder manage). I guess this is not implemented yet. > 3) Nova is used only in one case - Generic Driver that uses Cinder volumes. > So, it can be said, that Manila interface does allow to use "flat" network > and a share driver just should have implementation for it. I will assume you > mean usage of generic driver and possibility to mount shares to different > machines except Nova VMs. - In that case network architecture should allow to > make connection in general. If it is allowed, then should not be any problems > with mount to any machine. Just access-allow operations should be performed. This point was actually a copy from the wiki [1]. I just removed the Bare-metal point since for me it doesn’t matter whether the infrastructure service is a Bare-metal machine or not. > 4) Access can be shared, but it is not as flexible as could be wanted. Owner > of a share can grant access to all, and if there is network connectivity > between user and share host, then user will be able to mount having provided > access. Also a copy from the wiki. > 5) Manila can not remove some "mount" of some share, it can remove access for > possibility to mount in general. So, looks like not implemented. > 6) Implemented. > 7) Not implemented yet. > 8) No "cloning", but we have snapshot-approach as for volumes in cinder. Regards Marc > > Regards, > Valeriy Ponomaryov > Mirantis > > On Tue, Dec 2, 2014 at 4:22 PM, Marc Koderer <m...@koderer.com> wrote: > Hello Manila Team, > > We identified use cases for Manila during an internal workshop > with our operators. I would like to share them with you and > update the wiki [1] since it seems to be outdated. > > Before that I would like to gather feedback and you might help me > with identifying things that aren’t implemented yet. > > Our list: > > 1.) Create a share and use it in a tenant > Initial creation of a shared storage volume and assign it to several VM’s > > 2.) Assign an preexisting share to a VM with Manila > Import an existing Share with data and it to several VM’s in case of > migrating an existing production - services to Openstack. > > 3.) External consumption of a share > Accommodate and provide mechanisms for last-mile consumption of shares by > consumers of the service that aren't mediated by Nova. > > 4.) Cross Tenant sharing > Coordinate shares across tenants > > 5.) Detach a share and don’t destroy data (deactivate) > Share is flagged as inactive and data are not destroyed for later > usage or in case of legal requirements. > > 6.) Unassign and delete data of a share > Destroy entire share with all data and free space for further usage. > > 7.) Resize Share > Resize existing and assigned share on the fly. > > 8.) Copy existing share > Copy existing share between different storage technologies > > Regards > Marc > Deutsche Telekom > > [1]: https://wiki.openstack.org/wiki/Manila/usecases > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Kind Regards > Valeriy Ponomaryov > www.mirantis.com > vponomar...@mirantis.com > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
