Open Stack

Thomas Hervé <therve at gmail.com> wrote on 03.10.2013 09:59:02:

> From: Thomas Hervé <therve at gmail.com>
> To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>,
> Date: 03.10.2013 10:01
> Subject: Re: [openstack-dev] [Heat] Autoscale and load balancers
>
>
> On Wed, Oct 2, 2013 at 11:07 PM, Thomas
Spatzier <thomas.spatzier at de.ibm.com
> > wrote:
>
> A way to achieve the same behavior as you suggest but less verbose would
be
> to use relationships in HOT. We had some discussion about relationships
> earlier this year and in other contexts, but this would fit here very
well.
> And I think you express a similar idea on the wiki page you linked above.
> The model could look like:
>
> resources:
>   server1:
>     type: OS::Nova::Server
>   server2:
>     type: OS::Nova::Server
>   loadbalancer:
>     type: OS::Neutron::LoadBalancer
>     # properties etc.
>     relationships:
>       - member: server1
>       - member: server2
>
> From an implementation perspective, a relationship would be implemented
> similar to a resource, i.e. there is python code that implements all the
> behavior like modifying or notifying source or target of the
relationship.
> Only the look in the template is different. In the sample above, 'member'
> would be the type of relatioship and there would be a corresponding
> implementation. I actually wrote up some thoughts about possible notation
> for relationship in HOT on this wiki page:
> https://wiki.openstack.org/wiki/Heat/Software-Configuration-Provider
>
> We have such concepts in TOSCA and I think it could make sense to apply
> this here. So when evolving HOT we should think about extending a
template
> from just having resources to also having links (instead of association
> resources which are more verbose).
>
> 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.

Yes, good point. Relationships from the server to the LB make sense; it's
typically the one who wants to something ("the server wants to be
load-balanced") to refer to the one offering the service.

>
> 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.

If you refer to the components thing in the wiki page I mentioned, this has
been introduced (proposed) in relation to software orchestration. In the
first place, I thought it is not relevant for the loadbalancer use case but
the relationship concept is more important, and that was the reason I
pointed to that wiki page.
But actually you have a good point: it is the workload on-top of a server
that gets load balanced. So looks like both topics need to be looked at in
combination.

>
> --
> Thomas
>  _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev