Open Stack

Reply to Valeriy below and to Marc further below...


On 12/03/2014 02:39 AM, Valeriy Ponomaryov wrote:
> According to (2) - yes, analog of Cinder's "manage/unmanage" is not 
> implemented in Manila yet.

Manage/unmanage is a feature I'm very interested in seeing in Manila. I 
suspect it will be harder to get right in Manila than it was for Cinder, 
however, and more importantly, getting it right will depend a lot on the 
work that's going on right now to support pools and driver modes. For 
Manila core it won't actually be that much work but for individual 
drivers, implementing manage/unmanage can be a huge amount of work, so 
we should try to define the semantics of manage/unmanage at the project 
level to strike a good balance between usefulness to administrators and 
making it practical to implement.

> On Wed, Dec 3, 2014 at 9:03 AM, Marc Koderer <marc at koderer.com 
> <mailto:marc at koderer.com>> wrote:
>
>     Hi Valeriy,
>
>     thanks for feedback. My answers see below.
>
>     Am 02.12.2014 um 16:44 schrieb Valeriy Ponomaryov
>     <vponomaryov at mirantis.com <mailto:vponomaryov at 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 <marc at koderer.com
>     <mailto:marc at 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
>

This is the basic use case for Manila and I hope it's obvious that this 
works.

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

Covered above.

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

Depending on how you look at this, it either already works or it's out 
of scope for Manila. Now that we're looking at mount automation we may 
be more involved in this area, but nothing about Manila prevents the use 
of shares by something other than nova.

>     >  4.) Cross Tenant sharing
>     >      Coordinate shares across tenants
>

As above, this is considered out of scope, but we believe it's easy to 
make this work with no changes to Manila.

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

Can't this be achieved by simply removing all access? By default, the 
shares manila creates are not accessible to anyone. Access must be 
granted explicitly.

>     >  6.) Unassign and delete data of a share
>     >      Destroy entire share with all data and free space for
>     further usage.
>

This is another core feature that already works.

>     >  7.) Resize Share
>     >      Resize existing and assigned share on the fly.
>

Similar to manage/unmanage, this is very easily to conceptually 
understand, but not always easy to implement, due to the vagaries of 
real storage systems. There are some storage systems that can easily do 
this (such as NetApp) but others would find it quite challenging. 
Interestingly, for those that have difficulty resizing shares, resizing 
larger is often easier than resizing smaller. Cinder has made the design 
choice to support expanding volumes but NOT to support shrinking 
volumes. This is an area where we should consider making the resize 
feature optional, or at least making the shrinking optional if we decide 
to support expanding across the board.

>     >  8.) Copy existing share
>     >      Copy existing share between different storage technologies
>

Is this an analog for the cinder migrate feature? Hopefully it's obvious 
that anyone can copy a share to another share with the "cp -ar" command 
from a host that's connected to both shares. For copying across 
technologies, I suspect you can't do much better than this. For copying 
within the same family of backends, we already have snapshot and 
create-share-from-snapshot, and we could add optimized migration paths 
if we did implement a manila-managed migration feature.

>     > Regards
>     > Marc
>     > Deutsche Telekom
>     >
>     > [1]: https://wiki.openstack.org/wiki/Manila/usecases
>     >
>     >
>     >
>     > _______________________________________________
>     > OpenStack-dev mailing list
>     > OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
>     >
>     >
>     > --
>     > Kind Regards
>     > Valeriy Ponomaryov
>     > www.mirantis.com <http://www.mirantis.com>
>     > vponomaryov at mirantis.com <mailto:vponomaryov at mirantis.com>
>     > _______________________________________________
>     > OpenStack-dev mailing list
>     > OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> -- 
> Kind Regards
> Valeriy Ponomaryov
> www.mirantis.com <http://www.mirantis.com>
> vponomaryov at mirantis.com <mailto:vponomaryov at mirantis.com>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141203/6127e217/attachment.html>