For decom (now "zapping"), I'm building it with config flags to either disable it entirely, or just disable the erase_disks steps. No comment on the daft bit :) But I do understand why you'd want to do it this way.
https://review.openstack.org/#/c/102685/ On Fri Nov 14 2014 at 6:14:13 AM Clint Byrum <cl...@fewbar.com> wrote: > 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. 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 > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev