[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