[openstack-dev] [Manila] Expected Manila behavior for creation of share from snapshot

Ben Swartzlander ben at swartzlander.org
Thu Jun 18 12:46:40 UTC 2015


On 06/18/2015 07:08 AM, Deepak Shetty wrote:
>
>
> On Thu, Jun 18, 2015 at 8:43 AM, Ben Swartzlander 
> <ben at swartzlander.org <mailto:ben at swartzlander.org>> wrote:
>
>     On 06/03/2015 12:43 PM, Deepak Shetty wrote:
>>
>>
>>     On Tue, Jun 2, 2015 at 4:42 PM, Valeriy Ponomaryov
>>     <vponomaryov at mirantis.com <mailto:vponomaryov at mirantis.com>> wrote:
>>
>>         Deepak,
>>
>>         "transfer-*" is not suitable in this particular case. Usage
>>         of share networks causes creation of resources, when
>>         "transfer" does not. Also in this topic we have "creation" of
>>         new share based on some snapshot.
>>
>>
>>     In the original mail it was said:
>>     "
>>     From user point of view, he may want to copy share and use its
>>     copy in different network and it is valid case.
>>     "
>>     So create share from snapshot, then transfer that share to a
>>     different tenant , doesn't that work ?
>
>
>     Transferring shares between tenants is not something we've
>     discussed before. The cinder project allows transferring of
>     volumes but its easier for them to implement that feature because
>     they don't have the concepts of share networks and share servers
>     to tie the share to a tenant.
>
>     We implemented "public shares" which allows a similar use case
>     where 1 tenant can allow others to read/write to a share and
>     should address many of the same use cases that share transferring
>     would address.
>
>     -Ben
>
>
>
>>
>>         Valeriy
>>
>>         On Sun, May 31, 2015 at 4:23 PM, Deepak Shetty
>>         <dpkshetty at gmail.com <mailto:dpkshetty at gmail.com>> wrote:
>>
>>
>>             On Thu, May 28, 2015 at 4:54 PM, Duncan Thomas
>>             <duncan.thomas at gmail.com
>>             <mailto:duncan.thomas at gmail.com>> wrote:
>>
>>                 On 28 May 2015 at 13:03, Deepak Shetty
>>                 <dpkshetty at gmail.com <mailto:dpkshetty at gmail.com>> wrote:
>>
>>                     Isn't this similar to what cinder transfer-* cmds
>>                     are for ? Ability to transfer cinder volume
>>                     across tenants
>>                     So Manila should be implementing the transfer-*
>>                     cmds, after which admin/user can create a clone
>>                     then initiate a transfer to a diff tenant ?
>>
>>
>>                 Cinder doesn't seem to have any concept analogous to
>>                 a share network from what I can see; the cinder
>>                 transfer commands are for moving a volume between
>>                 tenants, which is a different thing, I think.
>>
>
> I agree that 'share transfer' (like volume transfer of cinder) would 
> be more complex, but shouldn't be impossible.
> IIUC Its eq to creating a new share for the destination tenant (which 
> is same as create share for that tenant) and then copy data (or allow 
> backend to optimize if possible) then delete the source share

Yes, we can implement a share transfer, but I'm arguing that we don't 
need to. Such a feature would be a lot of effort to implement for 
(arguably) little gain.

>>
>>             Yes, cinder doesn't have any eq of share network. But my
>>             comment was from the functionality perpsective. In cinder
>>             transfer-* commands are used to transfer ownership of
>>             volumes across tenants. IIUC the ability in Manila to
>>             create a share from snapshot and have that share in a
>>             different share network is eq to creating a share from a
>>             snapshot for a different tenant, no ? Share networks are
>>             typically 1-1 with tenant network AFAIK, correct me if i
>>             am wrong
>>
>
> Didn't knew this.... just wondering, this means the public share can 
> be accessed by multiple tenants ? Doesn't that break the tenant 
> isolation ?


Yes this was the point of public shares. It doesn't break tenant 
isolation any more than a feature like share transfer would. It's 
optional and you have to turn it on explicitly on a per-share basis. 
Also, the most common application for public shares would be in a 
read-only mode, so the possibility for bad things to happen is very small.


>
> thanx,
> deepak
>
>>
>>
>>                 -- 
>>                 Duncan Thomas
>>
>>                 __________________________________________________________________________
>>                 OpenStack Development Mailing List (not for usage
>>                 questions)
>>                 Unsubscribe:
>>                 OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>                 <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>>             <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>>         <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe  <mailto:OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> 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/20150618/fd4c0600/attachment.html>


More information about the OpenStack-dev mailing list