On Thu, Jul 4, 2013 at 6:16 PM, pablo fernandez
<fernandezpabl...@gmail.com> wrote:
> Leandro, Brano,
I wrote the previous mail in a hurry.. I hope this one might clarify it a bit
1) DFM dataset metadata
Folsom driver is using DFM to store Project id (tenant) together with
the volume. Essex driver did not do that, so his volumes are missing
this metadata. When Folsom driver starts, it will ask DFM for the list
of datasets and he will pick only those name starts with the right
prefix ("OpenStack_") and contain this metadata. If I run the script I
get something like..
OpenStack_5d8e3d0868f54879a13dbc8a3b3dcac5
(ArrayOfDfmMetadataField){
DfmMetadataField[] =
(DfmMetadataField){
FieldName = "OpenStackProject"
FieldValue = "5d8e3d0868f54879a13dbc8a3b3dcac5"
},
(DfmMetadataField){
FieldName = "OpenStackVolType"
FieldValue = None
},
}
This is the output for a volume created by Folsom driver. Essex volume
would have that array empty.
The same script allows you to add metadata (if missing) to existing
volumes created in Essex.
If your Folsom installation is using different datasets (created in
Folsom), then you can ignore this comment. This only applies to you if
you plan to point Folsom driver to LUNs/volumes created in Essex.
2) UUID
If you plan to install Folsom by running DB migration scripts on a
copy of Essex database, then it will take care of generating uuids for
existing volumes and updating all foreign key references.
However, if you start with "blank" Folsom and plan to manually insert
one-by-one entries for Essex volumes, it's much more difficult.
Especially if you have snapshots and volumes created from snapshots
(they reference each other)
3) Update "host"
When you attach a volume, nova-compute will contact via RPC a node
which is specified in "host" column. For example, you have there
"cloud-desa03", which I assume is Essex's nova-volume with Netapp
driver. You will have to update this field to point to Folsom
nova-volume host (assuming you have it on separate node).
4) access Essex volume/snapshot from Folsom
After migration some operations on Essex volumes might not work in
Folsom. I'm quite certain that create Folsom volume from Essex
snapshot did not work. That's why we had to patch Folsom driver to
fall back to lookup LUN by EC2 id, instead of UUID. Eg. driver will
receive a request to delete snapshot. He will get snapshot's name
("snap-a9922eaf-a001-4c53-a584-1b57d45b6e21") as input parameter. So
he will try to find a LUN whose name ends with that string. However,
because the snapshot was created in Essex, the name of the LUN ends
with "/snap-00000069". Operation will fail with "no such LUN.."
You might be lucky enough that you won't need any of those use-cases.
For example, attach/detach will probably work without any change.
Regards,
BranoZ
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
