Steve Baker <[email protected]> wrote on 21.11.2013 21:19:07: > From: Steve Baker <[email protected]> > To: [email protected], > 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 <[email protected]> > >> To: [email protected], > >> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
