Excerpts from Steve Baker's message of 2013-11-19 13:06:21 -0800: > On 11/20/2013 09:50 AM, Clint Byrum wrote: > > Excerpts from Steve Baker's message of 2013-11-18 12:52:04 -0800: > >> Regarding apply_config/remove_config, if a SoftwareApplier resource is > >> deleted it should trigger any remove_config and wait for the server to > >> acknowledge when that is complete. This allows for any > >> evacuation/deregistering workloads to be executed. > >> > > I'm a little worried about the road that leads us down. Most configuration > > software defines forward progress only. Meaning, if you want something > > not there, you don't remove it from your assertions, you assert that it > > is not there. > > > > The reason this is different than the way we operate with resources is > > that resources are all under Heat's direct control via well defined > > APIs. In-instance things, however, will be indirectly controlled. So I > > feel like focusing on a "diff" mechanism for user-deployed tools may be > > unnecessary and might confuse. I'd much rather have a "converge" > > mechanism for the users to focus on. > > > > > A specific use-case I'm trying to address here is tripleo doing an > update-replace on a nova compute node. The remove_config contains the > workload to evacuate VMs and signal heat when the node is ready to be > shut down. This is more involved than just "uninstall the things". > > Could you outline in some more detail how you think this could be done? >
So for that we would not remove the software configuration for the nova-compute, we would assert that the machine needs vms evacuated. We want evacuation to be something we explicitly do, not a side effect of deleting things. Perhaps having delete hooks for starting delete work-flows is right, but it set off a red flag for me so I want to make sure we think it through. Also IIRC, evacuation is not necessarily an in-instance thing. It looks more like the weird thing we've been talking about lately which is "how do we orchestrate tenant API's": https://etherpad.openstack.org/p/orchestrate-tenant-apis _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
