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 <sba...@redhat.com> >> To: openstack-dev@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 <cl...@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev