<div dir="ltr">Hi,<div><br></div><div>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:</div>
<div>1. Reusability - you can't reuse component without creating its definition copy with another placement parameter.</div><div>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.</div>
<div>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.</div><div>
<br></div><div>Thanks</div><div>Georgy</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 12, 2013 at 10:32 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Thomas Spatzier's message of 2013-11-11 08:57:58 -0800:<br>
<div class="im">><br>
> Hi all,<br>
><br>
> I have just posted the following wiki page to reflect a refined proposal<br>
> for HOT software configuration based on discussions at the design summit<br>
> last week. Angus also put a sample up in an etherpad last week, but we did<br>
> not have enough time to go thru it in the design session. My write-up is<br>
> based on Angus' sample, actually a refinement, and on discussions we had in<br>
> breaks, plus it is trying to reflect all the good input from ML discussions<br>
> and Steve Baker's initial proposal.<br>
><br>
> <a href="https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-WIP" target="_blank">https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-WIP</a><br>
><br>
> Please review and provide feedback.<br>
<br>
</div>Hi Thomas, thanks for spelling this out clearly.<br>
<br>
I am still -1 on anything that specifies the place a configuration is<br>
hosted inside the configuration definition itself. Because configurations<br>
are encapsulated by servers, it makes more sense to me that the servers<br>
(or server groups) would specify their configurations. If changing to a<br>
more logical model is just too hard for TOSCA to adapt to, then I suggest<br>
this be an area that TOSCA differs from Heat. We don't need two models<br>
for communicating configurations to servers, and I'd prefer Heat stay<br>
focused on making HOT template authors' and users' lives better.<br>
<br>
I have seen an alternative approach which separates a configuration<br>
definition from a configuration deployer. This at least makes it clear<br>
that the configuration is a part of a server. In pseudo-HOT:<br>
<br>
resources:<br>
WebConfig:<br>
type: OS::Heat::ChefCookbook<br>
properties:<br>
cookbook_url: <a href="https://some.test/foo" target="_blank">https://some.test/foo</a><br>
parameters:<br>
endpoint_host:<br>
type: string<br>
WebServer:<br>
type: OS::Nova::Server<br>
properties:<br>
image: webserver<br>
flavor: 100<br>
DeployWebConfig:<br>
type: OS::Heat::ConfigDeployer<br>
properties:<br>
configuration: {get_resource: WebConfig}<br>
on_server: {get_resource: WebServer}<br>
parameters:<br>
endpoint_host: {get_attribute: [ WebServer, first_ip]}<br>
<br>
I have implementation questions about both of these approaches though,<br>
as it appears they'd have to reach backward in the graph to insert<br>
their configuration, or have a generic bucket for all configuration<br>
to be inserted. IMO that would look a lot like the method I proposed,<br>
which was to just have a list of components attached directly to the<br>
server like this:<br>
<br>
components:<br>
WebConfig:<br>
type: Chef::Cookbook<br>
properties:<br>
cookbook_url: <a href="https://some.test/foo" target="_blank">https://some.test/foo</a><br>
parameters:<br>
endpoing_host:<br>
type: string<br>
resources:<br>
WebServer:<br>
type: OS::Nova::Server<br>
properties:<br>
image: webserver<br>
flavor: 100<br>
components:<br>
- webconfig:<br>
component: {get_component: WebConfig}<br>
parameters:<br>
endpoint_host: {get_attribute: [ WebServer, first_ip ]}<br>
<br>
Of course, the keen eye will see the circular dependency there with the<br>
WebServer trying to know its own IP. We've identified quite a few use<br>
cases for self-referencing attributes, so that is a separate problem we<br>
should solve independent of the template composition problem.<br>
<br>
Anyway, I prefer the idea that parse-time things are called components<br>
and run-time things are resources. I don't need a database entry for<br>
"WebConfig" above. It is in the template and entirely static, just<br>
sitting there as a reusable chunk for servers to pull in as-needed.<br>
<br>
Anyway, I don't feel that we resolved any of these issues in the session<br>
about configuration at the summit. If we did, we did not record them<br>
in the etherpad or the blueprint. We barely got through the prepared<br>
list of requirements and only were able to spell out problems, not<br>
any solutions. So forgive me if I missed something and want to keep on<br>
discussing this.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Georgy Okrokvertskhov<br>
Technical Program Manager,<br>Cloud and Infrastructure Services,<br>
Mirantis<br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284<br>
</div>