Open Stack

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
>>
>> 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?
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 ;)

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

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

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.

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.