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. _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators