On 11/21/2013 11:41 AM, Clint Byrum wrote: > Excerpts from Mike Spreitzer's message of 2013-11-20 13:46:25 -0800: >> 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. >> > I am worried about the explosion of possibilities that comes from trying > to deal with all of the diff's possible inside an instance. If there is an > actual REST interface for a thing, then yes, let's use that. For instance, > if we are using docker, there is in fact a very straight forward way to > say "remove entity X". If we are using packages we have the same thing. > However, if we are just trying to write chef configurations, we have to > write reverse chef configurations. > > What I meant to convey is "let's give this piece of the interface a lot of > thought". Not "this is wrong to even have." Given a couple of days now, > I think we do need "apply" and "remove". We should also provide really > solid example templates for this concept. You're right, I'm already starting to see issues with my current approach.
This smells like a new blueprint. I'll remove it from the scope of the current software config work and raise a blueprint to track remove-config. >>>>> ... >>>> 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? >> > Autoscaling doesn't really fly with stateful services IMO. Also for > TripleO's use case, auto-scaling is not really a high priority. Hardware > isn't nearly as easily allocatable as VM's. > > Anyway, there is a really complicated work-flow for decomissioning > any stateful service, and it differs wildly between them. I do want to > have a place to define that work-flow and reliably trigger it when it > needs to be triggered. I do not want it to _only_ be available in the > "delete this resource" case, and I also do not want it to _always_ > be run in that case, as I may legitimately be destroying the data too. > I need a way to express that intention, and in my mind, the way to do > that is to first complete an evacuation and then delete the thing. > > Better ideas are _most_ welcome. > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
