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.<br><div><br></div><div><a href="https://review.openstack.org/#/c/102685/">https://review.openstack.org/#/c/102685/</a><br></div><br><div class="gmail_quote">On Fri Nov 14 2014 at 6:14:13 AM Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Chris Jones's message of 2014-11-14 00:42:48 -0800:<br>
> Hi<br>
><br>
> My thoughts:<br>
><br>
> 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?<br>
><br>
> 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!<br>
><br>
> Having said that, "preserve ephemeral" is a terrible oxymoron, so if we can do something about it, we probably should.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
<br>
+1<br>
<br>
A predictable and simple rule seems like it would go a long way to<br>
decoupling state preservation from rebuild, which I like very much.<br>
<br>
There is, of course, the issue of decom then, but that has never been a<br>
concern for TripleO, and for OnMetal, they think we're a bit daft trying<br>
to preserve state while delivering new images anyway. :)<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div>