According to (2) - yes, analog of Cinder's "manage/unmanage" is not
implemented in Manila yet.

On Wed, Dec 3, 2014 at 9:03 AM, Marc Koderer <m...@koderer.com> wrote:

> 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
>



-- 
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

Reply via email to