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 ? > 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. >>> >> >> 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 >> > >> >>> >>> -- >>> 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:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev