Open Stack

Excerpts from Steve Baker's message on 21.11.2013 00:00:47:
> From: Steve Baker <sbaker at redhat.com>
> To: openstack-dev at lists.openstack.org,
> Date: 21.11.2013 00:04
> Subject: Re: [openstack-dev] [Heat] HOT software configuration
> refined after design summit discussions
>
> 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:

<snip>

> >>
> > 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.

So I read thru those recent discussions and in parallel also started to
update the design wiki. BTW, nanjj renamed the wiki to [1] (but also made a
redirect from the previous ...-WIP page) and linked it as spec to BP [2].

I'll leave out the remove-config thing for now. While thinking about the
overall picture, I came up with some other comments:

I thought about the name "SoftwareApplier" some more and while it is clear
what it does (it applies a software config to a server), the naming is not
really consistent with all the other resources in Heat. Every other
resource type is called after the thing that you get when the template gets
instantiated (a "Server", a "FloatingIP", a "VolumeAttachment" etc). In
case of SoftwareApplier what you actually get from a user perspective is a
deployed instance of the piece of software described be a SoftwareConfig.
Therefore, I was calling it SoftwareDeployment orignally, because you get a
software deployment (according to a config). Any comments on that name?

If we think this thru with respect to "remove-config" (even though this
needs more thought), a SoftwareApplier (that thing itself) would not really
go to state DELETE_IN_PROGRESS during an update. It is always there on the
VM but the software it deploys gets deleted and then reapplied or
whatever ...

Now thinking more about update scenarios (which we can leave for an
iteration after the initial deployment is working), in my mental model it
would be more consistent to have information for "handle_create",
"handle_delete", "handle_update" kinds of events all defined in the
SoftwareConfig resource. SoftwareConfig for represent configuration
information for one specific piece of software, e.g. a web server. So it
could provide all the information you need to install it, to uninstall it,
or to update its config. By updating the SoftwareApplier's (or
SoftwareDeployment's - my preferred name) state at runtime, the in-instance
tools would grab the respective script of whatever an run it.

So SoftwareConfig could look like:

resources:
  my_webserver_config:
    type: OS::Heat::SoftwareConfig
    properties:
      http_port:
        type: number
      # some more config props

      config_create: http://www.example.com/my_scripts/webserver/install.sh
      config_delete:
http://www.example.com/my_scripts/webserver/uninstall.sh
      config_update:
http://www.example.com/my_scripts/webserver/applyupdate.sh


At runtime, when a SoftwareApplier gets created, it looks for the
'config_create' hook and triggers that automation. When it gets deleted, it
looks for the 'config_delete' hook and so on. Only config_create is
mandatory.
I think that would also give us nice extensibility for future use cases.
For example, Heat today does not support something like stop-stack or
start-stack which would be pretty useful though. If we have it one day, we
would just add a 'config_start' hook to the SoftwareConfig.


[1]
https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-spec
[2] https://blueprints.launchpad.net/heat/+spec/hot-software-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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>