On 06/18/2015 07:08 AM, Deepak Shetty wrote:
On Thu, Jun 18, 2015 at 8:43 AM, Ben Swartzlander
<b...@swartzlander.org <mailto: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 <mailto: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 <mailto:dpkshe...@gmail.com>> wrote:
On Thu, May 28, 2015 at 4:54 PM, Duncan Thomas
<duncan.tho...@gmail.com
<mailto:duncan.tho...@gmail.com>> wrote:
On 28 May 2015 at 13:03, Deepak Shetty
<dpkshe...@gmail.com <mailto: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.
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-requ...@lists.openstack.org?subject:unsubscribe
<http://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://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://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
<mailto: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://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
