On 11/19/2013 02:22 AM, Thomas Spatzier wrote: > Hi all, > > I have reworked the wiki page [1] I created last week to reflect > discussions we had on the mail list and in IRC. From ML discussions last > week it looked like we were all basically on the same page (with some > details to be worked out), and I hope the new draft eliminates some > confusion that the original draft had. > > [1] https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-WIP > Thanks Thomas, this looks really good. I've actually started on a POC which maps to this model.
I've used different semantics which you may actually prefer some of, please comment below. Resource types: SoftwareConfig -> SoftwareConfig (yay!) SoftwareDeployment -> SoftwareApplier - less typing, less mouth-fatigue SoftwareConfig properties: parameters -> inputs - just because parameters is overloaded already. Although if the CM tool has their own semantics for inputs then that should be used in that SoftwareConfig resource implementation instead. outputs -> outputs SoftwareApplier properties: software_config -> apply_config - because there will sometimes be a corresponding remove_config server -> server parameters -> input_values - to match the 'inputs' schema property in SoftwareConfig Other comments on hot-software-config-WIP: Regarding apply_config/remove_config, if a SoftwareApplier resource is deleted it should trigger any remove_config and wait for the server to acknowledge when that is complete. This allows for any evacuation/deregistering workloads to be executed. I'm unclear yet what the SoftwareConfig 'role' is for, unless the role specifies the contract for a given inputs and outputs schema? How would this be documented or enforced? I'm inclined to leave it out for now. It should be possible to write a SoftwareConfig type for a new CM tool as a provider template. This has some nice implications for deployers and users. My hope is that there will not need to be a different SoftwareApplier type written for each CM tool. But maybe there will be one for each delivery mechanism. The first implementation will use metadata polling and signals, another might use Marconi. Bootstrapping an image to consume a given CM tool and applied configuration data is something that we need to do, but we can make it beyond the scope of this particular proposal. The POC I'm working on is actually backed by a REST API which does dumb (but structured) storage of SoftwareConfig and SoftwareApplier entities. This has some interesting implications for managing SoftwareConfig resources outside the context of the stack which uses them, but lets not worry too much about that *yet*. cheers _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
