Hi Ben,
Those approaches are still the ones in place, and they are implemented in
the prototype. Just to recap:
Approach #1: Driver migration, optimized from same vendor, like netapp =
netapp. Driver should implement, does not require an additional DB row.
Approach #2: Generic Migration, when
On 05/28/2015 01:14 PM, Rodrigo Barbieri wrote:
For Share Migration, I am looking into integrating it with Private
Driver Storage as Valeriy mentioned. The purpose is in fact different
than not displaying the volume being migrated to the user, we are
attempting to not use a temporary DB entry
For Share Migration, I am looking into integrating it with Private Driver
Storage as Valeriy mentioned. The purpose is in fact different than not
displaying the volume being migrated to the user, we are attempting to not
use a temporary DB entry at all. I am not sure how this will play out,
Thanks for the info!
I think for the migration use case this would definitely solve the issue,
but for the image cache we would need more as we would be creating volume
objects and need to track them in the Cinder database. We could use a
system like that to essentially put a 'hidden' flag in the
This manilla feature is essentially the same as the admin metadata already
attached to the volume in cinder, but with a slightly nicer internal API.
It could be used for migration, though the fields essentially map onto
almost all of the fields already in a volume; that isn't necessarily a
Hi Valeriy,
Thank you for telling me about the private driver storage feature from
Manila. I have reviewed the patch and it can definitely resolve the dummy
destination volume issue I have during migration in Cinder. I do not deny
that it is a good approach.
However, I need to put Patrick in
