On 11/21/2013 10:46 AM, Mike Spreitzer wrote: > Clint Byrum <[email protected]> wrote on 11/19/2013 04:28:31 PM: > > From: Clint Byrum <[email protected]> > > To: openstack-dev <[email protected]>, > > Date: 11/19/2013 04:30 PM > > Subject: Re: [openstack-dev] [Heat] HOT software configuration > > refined after design summit discussions > > > > 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. > > I am worried too. But I do not entirely follow your reasoning. When > I UPDATE a stack with a new template, am I supposed to write in that > template not just what I want the stack to be but also how that > differs from what it currently is? That is not REST. Not that I am a > total REST zealot, but I am a fan of managing in terms of desired > state. But I agree there is a conflict between defining a 'remove' > operation and the "forward progress only" mindset of most config tooling. > As I'm currently proposing, here are some stack update scenarios: * update results in modified software config, apply_config will be executed again on the affected server * update results in a server that requires replacement. This results in: * execute the remove_config workload on that server. The SoftwareApplier resource remains in DELETE_IN_PROGRESS until signalled that remove_config is complete * delete the server * create the replacement server * execute apply_config on that server... > > > > ... > > > 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. > > Really? You want to force the user to explicitly say "evacuate the > VMs" in all the various ways a host deletion can happen? E.g., when > an autoscaling group of hosts shrinks? > Nobody is being forced. remove_config is entirely optional and only exists for the more complex scenarios requiring evacuation/deregistering.
If remove_config is not specified, the SoftwareApplier should probably go straight to DELETE_COMPLETE without waiting for any signal. > > 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 > > This looks promising to me. It looks like these might be represented as SoftwareConfigs
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
