On Thu, Jun 18, 2015 at 6:16 PM, Ben Swartzlander <b...@swartzlander.org> wrote:
> On 06/18/2015 07:08 AM, Deepak Shetty wrote: > > > > On Thu, Jun 18, 2015 at 8:43 AM, Ben Swartzlander <b...@swartzlander.org> > wrote: > >> On 06/03/2015 12:43 PM, Deepak Shetty wrote: >> >> >> >> On Tue, Jun 2, 2015 at 4:42 PM, Valeriy Ponomaryov < >> vponomar...@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 <dpkshe...@gmail.com> >>> wrote: >>> >>>> >>>> On Thu, May 28, 2015 at 4:54 PM, Duncan Thomas < >>>> duncan.tho...@gmail.com> wrote: >>>> >>>>> On 28 May 2015 at 13:03, Deepak Shetty <dpkshe...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev