Open Stack

On 11/21/2013 10:46 AM, Mike Spreitzer wrote:
> 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.
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131121/05b67099/attachment.html>