openstack team mailing list archive

[Brano Zarnovican <zarnovican@xxxxxxxxx>]

On Wed, Jul 3, 2013 at 11:24 PM, pablo fernandez
<fernandezpablo85@xxxxxxxxx> wrote:
> Hi list!
>
> Any advice on this? Has somebody already tried it (and hopefully succeeded).

We did this migration "in-place". On day D, we dumped Essex
Openstack/DFM DB and restored in Folsom. I have created a patch for
Folsom Netapp driver to recognize Essex volumes/snapshots.

I assume that both your clouds are hitting the same DFM. Otherwise,
you would have to migrate entries not only between Openstack DB, but
DFM DB, too. Would be painful..

Folsom Netapp driver has added some meta-data to Openstack datasets
(in DFM), so Folsom will not recognize DFM datasets created in Essex
(and hence all Essex LUNs would be invisible). I have added that
meta-data manually with the attached script.

Volume is identified by (host, provider_location). Host is the one
running nova-volume, provider_location is an object id in DFM db.. eg
("mgmt-netapp.example.com", 7574).

So if you are using the same DFM, provider_location won't change, but
you host probably would.

Problem would be that you need to migrate id from decimal to UUIDs. In
my case, this was done in Openstack DB as part of that in-place
migration. The mapping is stored in new table "volume_id_mappings".
Same comments apply also to snapshots. However, because of this UUID
change, volumes names (LUNs on Netapp) are expected in different
format.

Essex:
/OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-000009a4/vol-000009a4
Folsom:
/OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e

That was the reason for driver patch, so I did not have to rename
existing LUNs on Netapp and DFM.

It's almost easier to create all volumes in Folsom and dd the content ;-)

Regards,

BranoZ

Attachment: dfm_meta.py
Description: Binary data