Open Stack

Steve Baker <sbaker at redhat.com> wrote on 21.11.2013 21:19:07:
> From: Steve Baker <sbaker at redhat.com>
> To: openstack-dev at lists.openstack.org,
> Date: 21.11.2013 21:25
> Subject: Re: [openstack-dev] [Heat] HOT software configuration
> refined after design summit discussions
>
> On 11/21/2013 08:48 PM, Thomas Spatzier wrote:
> > 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
<snip>
> > 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?
> SoftwareDeployment is a better name, apart from those 3 extra letters.
> I'll rename my POC.  Sorry nannj, you'll need to rename them back ;)

Ok, I'll change the name back in the wiki :-)

>
> > 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
> >
> With the caveat that what we're discussing here is a future
enhancement...
>
> The problem I see with config_create/config_update/config_delete in a
> single SoftwareConfig is that we probably can't assume these 3 scripts
> consume the same inputs and produce the same outputs.

We could make it a convention that creators of software configs have to use
the same signature for the automation of create, delete etc. Or at least
input param names must be the same, while some pieces might take a subset
only. E.g. delete will probably take less inputs. This way we could have a
self-contained config.
As you said above, implementation-wise this is probably a future
enhancement, so once we have he config_create handling in place we could
just do a PoC patch on-top and try it out.

>
> Another option might be to have a separate confg/deployment pair for
> delete workloads, and a property on the deployment resource which states
> which phase the workload is executed in (create or delete).

Yes, this would be an option, but IMO a bit confusing for users. Especially
when I inspect a deployed stack, I would be wondering why there are many
SoftwareDeployment resources hanging around for the same piece of software
installed on a server.

>
> I'd like to think that special treatment for config_update won't be
> needed at all, since CM tools are supposed to be good at converging to
> whatever you specify.

I tend to agree that we could leave out config_update, if automation is
implemented idempotently (which should be the normal case for Chef).

>
> The POC is taking shape, but I need to figure out at what point it
> should be shared. An online chat soon would be useful.

Yeah, let's chat soon, e.g. on Monday. I would also like to get my hands
dirty again and it would be good to see how we can best split work. And we
can try to close some design issues.

>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>