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

Clint Byrum clint at fewbar.com
Fri Nov 14 14:08:42 UTC 2014


Excerpts from Chris Jones's message of 2014-11-14 00:42:48 -0800:
> Hi
> 
> My thoughts:
> 
> Shoe-horning the ephemeral partition into Cinder seems like a lot of pain for almost no gain[1]. The only gain I can think of would be that we could bring a node down, boot it into a special ramdisk that exposes the volume to the network, so cindery operations (e.g. migration) could be performed, but I'm not even sure if anyone is asking for that?
> 
> Forcing Cinder to understand and track something it can never normally do anything with, seems like we're just trying to squeeze ourselves into an ever-shrinking VM costume!
> 
> Having said that, "preserve ephemeral" is a terrible oxymoron, so if we can do something about it, we probably should.
> 
> How about instead, we teach Nova/Ironic about a concept of "no ephemeral"? They make a partition on the first disk for the first image they deploy, and then they never touch the other part(s) of the disk(s), until the instance is destroyed. This creates one additional burden for operators, which is to create and format a partition the first time they boot, but since this is a very small number of commands, and something we could trivially bake into our (root?) elements, I'm not sure it's a huge problem.
> 
> This gets rid of the cognitive dissonance of preserving something that is described as ephemeral, and (IMO) makes it extremely clear that OpenStack isn't going to touch anything but the first partition of the first disk. If this were baked into the flavour rather than something we tack onto a nova rebuild command, it offers greater safety for operators, against the risk of accidentallying a vital state partition with a misconstructed rebuild command.
> 

+1

A predictable and simple rule seems like it would go a long way to
decoupling state preservation from rebuild, which I like very much.

There is, of course, the issue of decom then, but that has never been a
concern for TripleO, and for OnMetal, they think we're a bit daft trying
to preserve state while delivering new images anyway. :)



More information about the OpenStack-dev mailing list