Open Stack

On Thu, Jul 4, 2013 at 6:16 PM, pablo fernandez
<fernandezpablo85 at 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