Open Stack

Thomas Hervé <therve at gmail.com> wrote on 02.10.2013 17:06:48:

> From: Thomas Hervé <therve at gmail.com>
> To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>,
> Date: 02.10.2013 17:09
> Subject: [openstack-dev] [Heat] Autoscale and load balancers
>
> Hi all,
>
> There is a small but important part of the autoscale design described in
> https://wiki.openstack.org/wiki/Heat/AutoScaling that we'd like to
> discuss to make sure everybody is on the same page. Namely, the
> relationship between an autoscaling group and a load balancer.
>
> In the current system, a group has references to load balancers, and
> signals them when the group changes, sending it the list of servers
> in the group. This creates an implicit interface between groups and
> load balancers that we didn't model well, and is awkward for third-
> party load balancers.
>
> In the new design, the suggestion is to have an intermediate
> resource which models the relationship between the load balancer and
> its members. This resource would be instantiated every time an
> instance is added (or removed) and would notify the load balancer.
> There are some more details here: https://wiki.openstack.org/wiki/
> Heat/AutoScaling#Load_Balancers.

I think overall this design makes sense. I have a few thoughts on the
additional resource below.

>
> Pros:
>  * Remove load balancer specific code from the autoscale implementation.
>  * Map nicely to the neutron lbaas code, which has a 'add-member' API.
>  * Provide a more generic model for notifying systems of servers
allocation.
>
> Cons:
>  * Make the template a bit more verbose.
>
> We have some ideas on how to alleviate the verbosity concern, for
> example by creating a LoadBalancerServer resource which would embed
> a Server and a LoadBalancerMember resource. But the template being
> Heat's main UI, it's important to get a good story here.
>
> Thoughts?

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

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