Georgy Okrokvertskhov <gokrokvertsk...@mirantis.com> wrote on 12.11.2013 21:27:13: > From: Georgy Okrokvertskhov <gokrokvertsk...@mirantis.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org>, > Date: 12.11.2013 21:29 > Subject: Re: [openstack-dev] [Heat] HOT software configuration > refined after design summit discussions > > Hi, > > I agree with Clint that component placement specified inside > component configuration is not a right thing. I remember that mostly > everyone agreed that "hosted_on" should not be in HOT templates. > When one specify placement explicitly inside a component definition > it prevents the following: > 1. Reusability - you can't reuse component without creating its > definition copy with another placement parameter.
See my reply to Clint's mail. The deployment location in form of the "server" reference is _not_ hardcoded in the component definition. All we do is to provide a pointer to the server where a software shall be deployed at deploy time. You can use a component definition in many place, and in each place where you use it you provide it a pointer to the target server. > 2. Composability - it will be no clear way to express composable > configurations. There was a clear way in a template showed during > design session where server had a list of components to be placed. I think we have full composability with the "deployment" resources that mark uses of software component definitions. > 3. Deployment order - some components should be placed in strict > order and it will be much easier just make an ordered list of > components then express artificial dependencies between them just > for ordering. With the "deployment" resources and Heat's normal way of handling dependencies between any resources, we should be able have proper ordering. I agree that strict ordering is probably the most easy way of doing it, but we have implementations that do deployment in a more flexible manner without any problems. > > Thanks > Georgy > > On Tue, Nov 12, 2013 at 10:32 AM, Clint Byrum <cl...@fewbar.com> wrote: > 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 > > for HOT software configuration based on discussions at the design summit > > last week. Angus also put a sample up in an etherpad last week, but we did > > not have enough time to go thru it in the design session. My write-up is > > based on Angus' sample, actually a refinement, and on discussions we had in > > breaks, plus it is trying to reflect all the good input from ML discussions > > and Steve Baker's initial proposal. > > > > https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-WIP > > > > Please review and provide feedback. > 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 > 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 > 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]} > > I have implementation questions about both of these approaches though, > as it appears they'd have to reach backward in the graph to insert > their configuration, or have a generic bucket for all configuration > to be inserted. IMO that would look a lot like the method I proposed, > which was to just have a list of components attached directly to the > server like this: > > components: > WebConfig: > type: Chef::Cookbook > properties: > cookbook_url: https://some.test/foo > parameters: > endpoing_host: > type: string > resources: > WebServer: > type: OS::Nova::Server > properties: > image: webserver > flavor: 100 > components: > - webconfig: > component: {get_component: WebConfig} > parameters: > endpoint_host: {get_attribute: [ WebServer, first_ip ]} > > Of course, the keen eye will see the circular dependency there with the > WebServer trying to know its own IP. We've identified quite a few use > cases for self-referencing attributes, so that is a separate problem we > should solve independent of the template composition problem. > > Anyway, I prefer the idea that parse-time things are called components > and run-time things are resources. I don't need a database entry for > "WebConfig" above. It is in the template and entirely static, just > sitting there as a reusable chunk for servers to pull in as-needed. > > Anyway, I don't feel that we resolved any of these issues in the session > about configuration at the summit. If we did, we did not record them > in the etherpad or the blueprint. We barely got through the prepared > list of requirements and only were able to spell out problems, not > any solutions. So forgive me if I missed something and want to keep on > discussing this. > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > -- > Georgy Okrokvertskhov > Technical Program Manager, > Cloud and Infrastructure Services, > Mirantis > http://www.mirantis.com > Tel. +1 650 963 9828 > Mob. +1 650 996 3284_______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
