<div dir="ltr"><br><div class="gmail_extra"><br>On Wed, Oct 2, 2013 at 11:07 PM, Thomas Spatzier <span dir="ltr"><<a href="mailto:thomas.spatzier@de.ibm.com" target="_blank">thomas.spatzier@de.ibm.com</a>></span> wrote:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A way to achieve the same behavior as you suggest but less verbose would be<br>

to use relationships in HOT. We had some discussion about relationships<br>
earlier this year and in other contexts, but this would fit here very well.<br>
And I think you express a similar idea on the wiki page you linked above.<br>
The model could look like:<br>
<br>
resources:<br>
  server1:<br>
    type: OS::Nova::Server<br>
  server2:<br>
    type: OS::Nova::Server<br>
  loadbalancer:<br>
    type: OS::Neutron::LoadBalancer<br>
    # properties etc.<br>
    relationships:<br>
      - member: server1<br>
      - member: server2<br>
<br>
>From an implementation perspective, a relationship would be implemented<br>
similar to a resource, i.e. there is python code that implements all the<br>
behavior like modifying or notifying source or target of the relationship.<br>
Only the look in the template is different. In the sample above, 'member'<br>
would be the type of relatioship and there would be a corresponding<br>
implementation. I actually wrote up some thoughts about possible notation<br>
for relationship in HOT on this wiki page:<br>
<a href="https://wiki.openstack.org/wiki/Heat/Software-Configuration-Provider" target="_blank">https://wiki.openstack.org/wiki/Heat/Software-Configuration-Provider</a><br>
<br>
We have such concepts in TOSCA and I think it could make sense to apply<br>
this here. So when evolving HOT we should think about extending a template<br>
from just having resources to also having links (instead of association<br>
resources which are more verbose).<br></blockquote><div><br></div><div>Thanks for the input, I like the way it's structured. In this particular case, I think I'd like the relationships to be on server instead of having a list of relationships on the load balancer, but the idea remains the same.</div>
<div><br></div><div>I didn't grasp completely the idea of components just yet, but it seems it would be a useful distinction with resources here, as we care more about the actual application here (the service running on port N on the server), rather than the bare server. It becomes the responsibility of the application to register with the load balancer, which it can do in a more informed manner (providing the weight in the pool for example). We just need a concise and explicit way to do that in a template.</div>
<div><br></div><div>-- </div><div>Thomas</div><div> </div></div></div></div>