Open Stack

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 <clint at 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[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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141114/fc83a10c/attachment.html>