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

Deepak Shetty dpkshetty at gmail.com
Thu Jun 18 11:08:30 UTC 2015


On Thu, Jun 18, 2015 at 8:43 AM, Ben Swartzlander <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> 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>
>> wrote:
>>
>>>
>>>  On Thu, May 28, 2015 at 4:54 PM, Duncan Thomas <duncan.thomas at gmail.com
>>> > wrote:
>>>
>>>> On 28 May 2015 at 13:03, Deepak Shetty <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, 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 ?

thanx,
deepak


>
>>>
>>>>
>>>> --
>>>> Duncan Thomas
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>>>
>>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://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/b0fd2b39/attachment.html>


More information about the OpenStack-dev mailing list