Open Stack

Excerpts from Chris Friesen's message of 2017-10-04 09:15:28 -0600:
> On 10/03/2017 11:12 AM, Clint Byrum wrote:
> 
> > My personal opinion is that rebuild is an anti-pattern for cloud, and
> > should be frozen and deprecated. It does nothing but complicate Nova
> > and present challenges for scaling.
> >
> > That said, if it must stay as a feature, I don't think updating the
> > user_data should be a priority. At that point, you've basically created an
> > entirely new server, and you can already do that by creating an entirely
> > new server.
> 
> If you've got a whole heat stack with multiple resources, and you realize that 
> you messed up one thing in the template and one of your servers has the wrong 
> personality/user_data, it can be useful to be able to rebuild that one server 
> without affecting anything else in the stack.  That's just a convenience though.
> 

If you just changed that personality/user_data in the template, Heat
would spin up a new one, change all the references to it, wait for any
wait conditions to fire, allowing dependent servers to reconfigure with
the new one and acknowledge that, and then delete the old one for you.

Making your app work like this means being able to replace failed or
undersized servers with less downtime. You can do other things too,
like spin up a replacement in a different AZ to deal with maintenance
issues on your side or the cloud's side. Or you can deploy a new image,
without any downtime.

My point remains: rebuild (and resize) train users to see a server as
precious, instead of training users to write automation that expects
cloud servers to come and go often.

This, btw, is one reason I like that EC2 calls them _instances_ and not
_servers_. They're not servers. We call them servers, but they're just
little regions of memory on actual servers, and as such, they're not
precious, and should be discarded as necessary.