[openstack-dev] [TripleO] [Ironic] [Cinder] "Baremetal volumes" -- how to model direct attached storage

Clint Byrum clint at fewbar.com
Wed Nov 12 22:30:11 UTC 2014


Each summit since we created "preserve ephemeral" mode in Nova, I have
some conversations where at least one person's brain breaks for a
second. There isn't always alcohol involved before, there almost
certainly is always a drink needed after. The very term is vexing, and I
think we have done ourselves a disservice to have it, even if it was the
best option at the time.

To be clear, in TripleO, we need a way to keep the data on a local
direct attached storage device while deploying a new image to the box.
If we were on VMs, we'd attach volumes, and just deploy new VMs and move
the volume over. If we had a SAN, we'd just move the LUN's. But at some
point when you deploy a cloud you're holding data that is expensive to
replicate all at once, and so you'd rather just keep using the same
server instead of trying to move the data.

Since we don't have baremetal Cinder, we had to come up with a way to
do this, so we used Nova rebuild, and slipped it a special command that
said "don't overwrite the partition you'd normally make the 'ephemeral'"
partition. This works fine, but it is confusing and limiting. We'd like
something better.

I had an interesting discussion with Devananda in which he suggested an
alternative approach. If we were to bring up cinder-volume on our deploy
ramdisks, and configure it in such a way that it claimed ownership of
the section of disk we'd like to preserve, then we could allocate that
storage as a volume. From there, we could boot from volume, or "attach"
the volume to the instance (which would really just tell us how to find
the volume). When we want to write a new image, we can just delete the old
instance and create a new one, scheduled to wherever that volume already
is. This would require the nova scheduler to have a filter available
where we could select a host by the volumes it has, so we can make sure to
send the instance request back to the box that still has all of the data.

Alternatively we can keep on using rebuild, but let the volume model the
preservation rather than our special case.

Thoughts? Suggestions? I feel like this might take some time, but it is
necessary to consider it now so we can drive any work we need to get it
done soon.



More information about the OpenStack-dev mailing list