<div dir="ltr">According to (2) - yes, analog of Cinder's "manage/unmanage" is not implemented in Manila yet.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 3, 2014 at 9:03 AM, Marc Koderer <span dir="ltr"><<a href="mailto:marc@koderer.com" target="_blank">marc@koderer.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Valeriy,<br>
<br>
thanks for feedback. My answers see below.<br>
<br>
Am 02.12.2014 um 16:44 schrieb Valeriy Ponomaryov <<a href="mailto:vponomaryov@mirantis.com">vponomaryov@mirantis.com</a>>:<br>
<span class=""><br>
> Hello Marc,<br>
><br>
> Here, I tried to cover mentioned use cases with "implemented or not" notes:<br>
><br>
> 1) Implemented, but details of implementation are different for different share drivers.<br>
> 2) Not clear for me. If you mean possibility to mount one share to any amount of VMs, then yes.<br>
<br>
</span>That means you have an existing shared volume in your storage system and import<br>
it to manila (like cinder manage). I guess this is not implemented yet.<br>
<span class=""><br>
> 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.<br>
<br>
</span>This point was actually a copy from the wiki [1]. I just removed the Bare-metal point<br>
since for me it doesn’t matter whether the infrastructure service is a Bare-metal machine or not.<br>
<span class=""><br>
> 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.<br>
<br>
</span>Also a copy from the wiki.<br>
<span class="im HOEnZb"><br>
> 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.<br>
> 6) Implemented.<br>
> 7) Not implemented yet.<br>
> 8) No "cloning", but we have snapshot-approach as for volumes in cinder.<br>
<br>
Regards<br>
</span><span class="HOEnZb"><font color="#888888">Marc<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Regards,<br>
> Valeriy Ponomaryov<br>
> Mirantis<br>
><br>
> On Tue, Dec 2, 2014 at 4:22 PM, Marc Koderer <<a href="mailto:marc@koderer.com">marc@koderer.com</a>> wrote:<br>
> Hello Manila Team,<br>
><br>
> We identified use cases for Manila during an internal workshop<br>
> with our operators. I would like to share them with you and<br>
> update the wiki [1] since it seems to be outdated.<br>
><br>
> Before that I would like to gather feedback and you might help me<br>
> with identifying things that aren’t implemented yet.<br>
><br>
> Our list:<br>
><br>
> 1.) Create a share and use it in a tenant<br>
> Initial creation of a shared storage volume and assign it to several VM’s<br>
><br>
> 2.) Assign an preexisting share to a VM with Manila<br>
> Import an existing Share with data and it to several VM’s in case of<br>
> migrating an existing production - services to Openstack.<br>
><br>
> 3.) External consumption of a share<br>
> Accommodate and provide mechanisms for last-mile consumption of shares by<br>
> consumers of the service that aren't mediated by Nova.<br>
><br>
> 4.) Cross Tenant sharing<br>
> Coordinate shares across tenants<br>
><br>
> 5.) Detach a share and don’t destroy data (deactivate)<br>
> Share is flagged as inactive and data are not destroyed for later<br>
> usage or in case of legal requirements.<br>
><br>
> 6.) Unassign and delete data of a share<br>
> Destroy entire share with all data and free space for further usage.<br>
><br>
> 7.) Resize Share<br>
> Resize existing and assigned share on the fly.<br>
><br>
> 8.) Copy existing share<br>
> Copy existing share between different storage technologies<br>
><br>
> Regards<br>
> Marc<br>
> Deutsche Telekom<br>
><br>
> [1]: <a href="https://wiki.openstack.org/wiki/Manila/usecases" target="_blank">https://wiki.openstack.org/wiki/Manila/usecases</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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>
> --<br>
> Kind Regards<br>
> Valeriy Ponomaryov<br>
> <a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a><br>
> <a href="mailto:vponomaryov@mirantis.com">vponomaryov@mirantis.com</a><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Kind Regards<br>Valeriy Ponomaryov<br><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a><br><a href="mailto:vponomaryov@mirantis.com" target="_blank">vponomaryov@mirantis.com</a><br></div></div>
</div>