<font size=2 face="sans-serif">I personally don't like the rename approach
(and I implemented it!). However, as Avishay says, we don't have
that many options.</font>
<br>
<br><font size=2 face="sans-serif">One thing that we could do is start
to use the admin_metadata associated with a volume to store a reference
to the volume other than the name (which is the UUID). However, this
requires that individual drivers must change to support that - e.g. the
Storwize driver could choose to store the vdisk ID/UUID in admin_metadata,
and use it whenever it needed to perform an operation on a volume. Similarly,
the LVM driver could do the same, and use that in preference to assuming
that the LVM was named from the volume['name'] if it existed, but these
are going to be fairly signficant changes.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,<br>
Geraint.</font>
<br>
<br>
<hr noshade><font size=2 color=#3f8080 face="sans-serif">Geraint North</font>
<br><font size=1 color=#3f8080 face="sans-serif">Storage Virtualization
Architect and Master Inventor, Cloud Systems Software.</font>
<br><font size=1 color=#3f8080 face="sans-serif">IBM Manchester Lab, UK</font><font size=2 color=#3f8080 face="sans-serif">.</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Avishay Traeger <avishay@stratoscale.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"OpenStack Development
Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">09/04/2014 11:23</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [openstack-dev]
[Cinder] Regarding manage_existing and unmanage</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>On Wed, Apr 9, 2014 at 8:35 AM, Deepak Shetty <</font><a href=mailto:dpkshetty@gmail.com target=_blank><font size=3 color=blue><u>dpkshetty@gmail.com</u></font></a><font size=3>>
wrote:</font>
<br>
<br><font size=3><br>
</font>
<br><font size=3>On Tue, Apr 8, 2014 at 6:24 PM, Avishay Traeger <</font><a href=mailto:avishay@stratoscale.com target=_blank><font size=3 color=blue><u>avishay@stratoscale.com</u></font></a><font size=3>>
wrote:</font>
<br><font size=3>On Tue, Apr 8, 2014 at 9:17 AM, Deepak Shetty <</font><a href=mailto:dpkshetty@gmail.com target=_blank><font size=3 color=blue><u>dpkshetty@gmail.com</u></font></a><font size=3>>
wrote:</font>
<br><font size=3>Hi List,</font>
<br><font size=3> I had few Qs on the implementation
of manage_existing and unmanage API extns<br>
<br>
1) For LVM case, it renames the lv.. isn't it better to use name_id (one
used during cinder migrate to keep id same for a diff backend name/id)
to map cinder name/id to backend name/id and thus avoid renaming the backend
storage. Renaming isn't good since it changes the original name of the
storage object and hence storage admin may lose track? The Storwize uses
UID and changes vdisk_name on the backend array which isn't good either.
Is renaming a must, if yes why ?</font>
<br>
<br><font size=3>'name_id' is an ID, like c8b3d8e2-2410-4362-b24b-548a13fa850b.</font>
<br><font size=3>In migration, both the original and new volumes use the
same template for volume names, just with a different ID, so name_id works
well for that. When importing a volume that wasn't created by Cinder,
chances are it won't conform to this template, and so name_id won't work
(i.e., I can call the volume 'my_very_important_db_volume', and name_id
can't help with that). When importing, the admin should give the
volume a proper name and description, and won't lose track of it - it is
now being managed by Cinder.</font>
<br>
<br><font size=3>Avishay,</font>
<br><font size=3> thanks for ur reply.. it did help. Just
one more Q tho...<br>
<br>
>>(i.e., I can call the volume 'my_very_important_db_volume',
and name_id can't help with that).</font>
<br><font size=3>This is the name of the volume. but isn't it common for
most arrays to provide name and ID (which is again UUID) for a volume on
the backend.. so name_id can still point to the UID which has the name
'my_very_important_db_volume'</font>
<br><font size=3>In fact in storwize, you are using vdisk_id itself and
changing the vdisk_name to match what the user gave.. and vdisk_id is a
UUID and matches w/ name_id format</font>
<br>
<br><font size=3>Not exactly, it's a number (like '5'), not a UUID like
c8b3d8e2-2410-4362-b24b-548a13fa850b</font>
<br><font size=3> </font>
<br><font size=3>Alternatively, does this mean we need to make name_id
a generic field (not a ID) and then use somethign like uuidutils.is_uuid_like()
to determine if its UUID or non-UUID and then backend will accordinly map
it ?<br>
</font>
<br><font size=3>Lastly, I said "storage admin will lose track
of it" bcos he would have named is "my_vol" and when he
asks cidner to manage it using "my_cinder_vol" its not expected
that u wud rename the volume's name on the backend :)</font>
<br><font size=3>I mean its good if we could implement manage_existing
w/o renaming as then it would seem like less disruptive :)</font>
<br>
<br><font size=3> I think there are a few trade-offs here - making
it less disruptive in this sense makes it more disruptive to:</font>
<br><font size=3>1. Managing the storage over its lifetime. If we
assume that the admin will stick with Cinder for managing their volumes,
and if they need to find the volume on the storage, it should be done uniformly
(i.e., go to the backend and find the volume named 'volume-%s' % name_id).</font>
<br><font size=3>2. The code, where a change of this kind could make things
messy. Basically the rename approach has a little bit of complexity
overhead when you do manage_existing, but from then on it's just like any
other volume. Otherwise, it's always a special case in different
code paths, which could be tricky.</font>
<br>
<br><font size=3>If you still feel that rename is wrong and that there
is a better approach, I encourage you to try, and post code if it works.
I don't mind being proved wrong. :)<br>
<br>
Thanks,</font>
<br><font size=3>Avishay</font><tt><font size=2>_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br><font size=2 face="sans-serif"><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU<br>
</font>