Hide Forgot
+++ This bug was initially created as a clone of Bug #1303094 +++ (cut out the long clone text, please look at the original bug if needed) There are new cases of property changes causing unwanted node replacement on upgrade Liberty. https://review.openstack.org/#/c/286739/ -- this patch could cause node replacement but probably doesn't unless the HostnameMap parameter is utilized. https://review.openstack.org/#/c/266930/ -- this patch is probably the cause for node replacement happening. Solution suggestion: There is already a fix for bug #1303094 to prevent node replacement because of user_data. Expanding that fix to prevent node replacement when changing any OS::Nova::Server properties would probably be desirable for TripleO. Node replacement because of properties changing could potentially result in data loss, so it would be good to have it completely prevented by default, and only enable it subsequently if we discover that we need it for some new feature, and when we're ready to deal with node replacement correctly.
(In reply to Jiri Stransky from comment #0) > +++ This bug was initially created as a clone of Bug #1303094 +++ > > (cut out the long clone text, please look at the original bug if needed) > > There are new cases of property changes causing unwanted node replacement on > upgrade Liberty. > > https://review.openstack.org/#/c/286739/ -- this patch could cause node > replacement but probably doesn't unless the HostnameMap parameter is > utilized. Changing the name property does not cause replacement [1] but there is a nova call made to perform the rename. > https://review.openstack.org/#/c/266930/ -- this patch is probably the cause > for node replacement happening. I would argue that upstream heat should ignore changes to scheduler_hints - replacing a server for changing a boot time hint seems extreme. > Solution suggestion: > > There is already a fix for bug #1303094 to prevent node replacement because > of user_data. Expanding that fix to prevent node replacement when changing > any OS::Nova::Server properties would probably be desirable for TripleO. > Node replacement because of properties changing could potentially result in > data loss, so it would be good to have it completely prevented by default, > and only enable it subsequently if we discover that we need it for some new > feature, and when we're ready to deal with node replacement correctly. Yes, we could continue to play whack-a-mole each time upgrade testing shows another property causing server replacement, but just preventing replacements altogether in our custom server resource seems like a good approach - and this would be a temporary measure until Mitaka when heat update restrictions can be used. [1] http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server-prop-name
(In reply to Steve Baker from comment #3) > I would argue that upstream heat should ignore changes to scheduler_hints - > replacing a server for changing a boot time hint seems extreme. That thought occurred to me too, but I'm not sure I agree. Say you have a bunch of servers deployed in random places and you want to start ensuring that e.g. some of them are co-located, how would you force that to happen? (Possible answer: rebuild rather than replace the servers if possible.) And if you didn't want that to happen, why would you have changed the scheduler hint?
sbaker fixup @ https://review.openstack.org/#/c/288273/ "Prevent any property change from replacing OS::Nova::Server"
Upstream stable/liberty change has landed, so this will make it into 8.0 on the next tripleo-common rebase (or backport, I don't know what process is being followed here) https://review.openstack.org/#/c/291771/
Verified: Environment: openstack-tripleo-common-0.3.1-1.el7ost.noarch Re-ran the deployment command with Add a yaml with " NovaComputeSchedulerHints: {"some": "json"} ". Got: Stack overcloud UPDATE_COMPLETE The nova uuid are the same as before.