Open Stack

On Thu, Jun 18, 2015 at 6:16 PM, Ben Swartzlander <ben at swartzlander.org>
wrote:

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

Well, I would argue that 'transfer' as a API does have value and
implementation being simple/complex shouldn't matter as long as there is
'value' in the API, so I disagree a bit here.


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

Not really, public share (IIUC) allows > 1 tenant to access/share the share
at the same time, while transfer ensures exclusivity to one share at a
time, so they are different

thanx,
deepak

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://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
>>
>>
>
>
> __________________________________________________________________________
> 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/98628e90/attachment.html>