Open Stack

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 <clint at fewbar.com> wrote on 11/19/2013 04:28:31 PM:
>>> From: Clint Byrum <clint at fewbar.com>
>>> To: openstack-dev <openstack-dev at lists.openstack.org>, 
>>> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev