<div dir="ltr"><div><div><div>Hello guys,<br><br></div><div>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.</div><div><br></div>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.<br><br></div>Current scenario (as of prototype):  <br></div>- 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.<br><br>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".<div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. <br> <br clear="all"><div><div>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. </div><div><br></div><div><br>-- <br><div>Rodrigo Barbieri<div>Computer Scientist</div><div>Federal University of São Carlos</div><div><a href="tel:%2811%29%2096889%203412" value="+5511968893412" target="_blank">(11) 96889 3412</a></div></div>
</div></div></div></div>