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. :) _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
