Open Stack

Hello guys,

I would like to bring everyone up to speed on this topic, since we have a
weekly meeting tomorrow and I would like to further discuss this, either
here or tomorrow at the meeting, since this is something that is a
pre-requisite for future features planned for liberty.

We had a discussion on IRC last week about possible improvements to Share
Migration concerning the IDs and additional temporary DB row. So far, our
conclusion has been that we prefer to have the additional DB row, but we
must deal with the fact that current architecture does not expect a Share
to have two separate IDs, the "API ID" and the "Driver ID". We have came up
with several ways to improve this, and we would like to continue the
discussion and decide how we can better improve it thinking about the
future features such as Replication and AZ.

Current scenario (as of prototype):
- Migration creates a totally new share in destination backend, copy data,
copy new DB values (such as destination export location) to the original DB
entry, and then deletes the new DB entry, and the source physical share.
The result is the original DB entry with the new DB values (such as
destination export location). In this prototype, the export location is
being used as "Driver ID", because it is derived from the "API ID". After
migration, the migrated Share has "API ID" X and export location Y, because
Y was derived from the temporary DB row created for the destination share.

Proposal 1: Use Private Driver Storage to store "Driver ID". This will
require all drivers to follow the guideline as implemented in the generic
driver, which manages the volume ID ("Driver ID" for this driver) separate
from the "API ID".

Proposal 2: Use additional DB column so we have separate IDs in each
column. This will require less effort from drivers, because this column
value can be transferred from the temporary DB row to the original DB
entry, similar to what is done with the export location column in the
prototype. Drivers can manage the value in this column if they want, but if
they do not, we can derive from the API ID if we continue to use the
approach currently implemented for Share Migration, and keep in mind that
for replication or other features, we need to fill this field with a value
as if we are creating a new share. This approach also has the disadvantage
of being confusing for debugging and require more changes in Manila Core
code, but at least this is handled by Manila Core code instead of Driver
code.

Additionally, proposal 1 can be mixed with proposal 2, if the Manila Core
code attempts to store the "Driver ID" value in Private Share Data instead
of column, but we argued that Manila Core should not touch Private Share
Data, we have not come to a conclusion on this.

Proposal 3: Create new table "instances" that will be linked to the "API
ID", so a share can have several instances, which have their own ID, and
only one is considered "Active". This approach sounds very interesting for
future features, the admin can find the ID for which instances are in the
backend through a "manila share-instances-show <share_id>" command. There
has been a lot of discussion regarding how we use the Instance ID, if we
provide them directly to drivers as if it was the API ID, or include in a
field in the Share object so the driver can continue to use the API ID and
reads the Instance ID if it wants (which makes it similar to proposal 1).
It was stated that for replication, drivers need to see the instance IDs,
so providing the Instance ID as if it was the API ID would not make much
sense here. This approach will also require a lot of changes on Manila Core
code, and depending on what we decide to do with the Instance ID regarding
drivers, may require no changes or minimal changes to drivers.

Proposal 4: Allow drivers to change the "API ID". The
advantages/disadvanges of this proposal are not very clear to me, it would
fix part of Share Migration problem (not sure if replication would need to
do the same), but I see as it breaking the concept that we were trying to
migrate a share, it becomes cloning shares and erasing the original, we do
not know how it would impact users, and certainly would be much less
transparent.

I think that from here we can proceed on expressing our concerns,
disadvantages or advantages or each approach, for other features as well
(Unfortunately I am familiar with migration only), develop each proposal
further with diagrams if that's the case, so we can decide on which one is
best for our future features.


-- 
Rodrigo Barbieri
Computer Scientist
Federal University of São Carlos
(11) 96889 3412
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150603/7e58332c/attachment.html>