Excerpts form Clint Byrum's message on 12.11.2013 19:32:50: > From: Clint Byrum <[email protected]> > To: openstack-dev <[email protected]>, > Date: 12.11.2013 19:35 > Subject: Re: [openstack-dev] [Heat] HOT software configuration > refined after design summit discussions > > Excerpts from Thomas Spatzier's message of 2013-11-11 08:57:58 -0800: > > > > Hi all, > > > > I have just posted the following wiki page to reflect a refined proposal <snip> > Hi Thomas, thanks for spelling this out clearly. > > I am still -1 on anything that specifies the place a configuration is > hosted inside the configuration definition itself. Because configurations > are encapsulated by servers, it makes more sense to me that the servers > (or server groups) would specify their configurations. If changing to a
IMO the current proposal does _not_ the concrete hosting inside component definition. The component definition is in this external template file and all we do is give it a pointer to the server at deploy time so that the implementation can perform whatever is needed to perform at that time. The resource in the actual template file is like the intermediate association resource you are suggesting below (similar to what VolumeAttachment does), so this is the place where you say which component gets deployed where. This represents a concrete use of a software component. Again, all we do is pass in a pointer to the server where _this use_ of the software component shall be installed. > more logical model is just too hard for TOSCA to adapt to, then I suggest > this be an area that TOSCA differs from Heat. We don't need two models The current proposal was done completely unrelated to TOSCA, but really just a try to have a pragmatic approach for solving the use cases we talked about. I don't really care in which directions the relations point. Both ways can be easily mapped to TOSCA. I just think the current proposal is intuitive, at least to me. And you could see it as kind of a short notation that avoids another association class. > for communicating configurations to servers, and I'd prefer Heat stay > focused on making HOT template authors' and users' lives better. > > I have seen an alternative approach which separates a configuration > definition from a configuration deployer. This at least makes it clear > that the configuration is a part of a server. In pseudo-HOT: > > resources: > WebConfig: > type: OS::Heat::ChefCookbook > properties: > cookbook_url: https://some.test/foo > parameters: > endpoint_host: > type: string > WebServer: > type: OS::Nova::Server > properties: > image: webserver > flavor: 100 > DeployWebConfig: > type: OS::Heat::ConfigDeployer > properties: > configuration: {get_resource: WebConfig} > on_server: {get_resource: WebServer} > parameters: > endpoint_host: {get_attribute: [ WebServer, first_ip]} The DeployWebConfig association class actually is the 'mysql' resource in the template on the wiki page. See the Design alternative section I put it. That would be fine with me as well. > <snip> _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
