The problem with considering it a cinder volume rather than a nova ephemeral volume is that it is just as leaky a set of semantics - cinder volumes can be detached, attached elsewhere, snapshotted, backed up, etc - a directly connected bare metal drive will be able to do none of these things.
That said, the upcoming cinder-agent code might be of use - it is designed to provide discovery and an API around local storage - but mapping bare metal drives as cinder volumes is really no better than mapping them as nova ephemeral drives - in both cases they don't match the semantics. I'd rather not bend the cinder semantics out of shape to clean up the nova ones. On 13 November 2014 00:30, Clint Byrum <cl...@fewbar.com> wrote: > 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. > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev