[dev] Brightbox load balancer support

[Tim Fletcher <ma...@tfletcher.com>]

Hi folks,

I've been trying to add support for the [Brightbox load balancer
API][1] to libcloud, and there's a bit of a mismatch between the two
models.

  [1]: https://api.gb1.brightbox.com/1.0/#load_balancer

>From what I can tell from reading through the code, the libcloud model
is that a load balancer has a public IP, a single port number, and it
balances traffic between multiple "members" (i.e. servers), each of
which has a public IP and a single port number. Is that correct?

There are several key differences between this and the Brightbox
model: a Brightbox load balancer can have multiple ports open;
Brightbox servers don't necessarily have a public IP (they can be
attached to a load balancer without one); and the ports for Brightbox
servers behind a load balancer have to be the same (the port mapping
is specified on the load balancer).

I'm unsure how to tackle this. Is it possible to generalise the
libcloud load balancer abstraction to support the Brightbox API
somehow?

Cheers,
Tim

Re: [dev] Brightbox load balancer support

[Tomaž Muraus <to...@apache.org>]

On Thu, Oct 27, 2011 at 5:20 PM, Tim Fletcher <ma...@tfletcher.com> wrote:

> Thanks for the quick replies.
>
>
> > Keep in mind that Libcloud is by definition a lowest common denominator
> > which means we need to sacrifice some not-so-common functionality to
> > make an API which works with a lot of providers.
>
> That makes sense, I was naively thinking all the functionality could
> be supported.
>
>
> So if I understand you both correctly, I can subclass Member and not
> worry about the IP addresses (they may be set, but doesn't matter as
> that information won't be used by the API itself). The loadbalancer
> subclass will use the server ids instead.
>

Correct.


>
> Then if we make the assumption that only one port will need to be open
> then that problem disappears. Load balancing multiple ports is then an
> edge case that isn't supported by libcloud. And if there are more
> providers that support multiple ports in future then the API could
> potentially be changed long term to support that.
>

Yep.


>
> All seems doable, i'll hopefully be able to implement this in the new
> couple of weeks.
>

Don't forget about the tests and let us know if you get stuck and need help
:)


>
> Cheers,
> Tim
>

Re: [dev] Brightbox load balancer support

[Tim Fletcher <ma...@tfletcher.com>]

Thanks for the quick replies.


> Keep in mind that Libcloud is by definition a lowest common denominator
> which means we need to sacrifice some not-so-common functionality to
> make an API which works with a lot of providers.

That makes sense, I was naively thinking all the functionality could
be supported.


So if I understand you both correctly, I can subclass Member and not
worry about the IP addresses (they may be set, but doesn't matter as
that information won't be used by the API itself). The loadbalancer
subclass will use the server ids instead.

Then if we make the assumption that only one port will need to be open
then that problem disappears. Load balancing multiple ports is then an
edge case that isn't supported by libcloud. And if there are more
providers that support multiple ports in future then the API could
potentially be changed long term to support that.

All seems doable, i'll hopefully be able to implement this in the new
couple of weeks.

Cheers,
Tim

Re: [dev] Brightbox load balancer support

[Tomaž Muraus <to...@apache.org>]

On Tue, Oct 25, 2011 at 5:20 PM, Tim Fletcher <ma...@tfletcher.com> wrote:

> Hi folks,
>

Hi.


>
> I've been trying to add support for the [Brightbox load balancer
> API][1] to libcloud, and there's a bit of a mismatch between the two
> models.
>
>  [1]: https://api.gb1.brightbox.com/1.0/#load_balancer
>
> From what I can tell from reading through the code, the libcloud model
> is that a load balancer has a public IP, a single port number, and it
> balances traffic between multiple "members" (i.e. servers), each of
> which has a public IP and a single port number. Is that correct?
>

Correct.


>
> There are several key differences between this and the Brightbox
> model: a Brightbox load balancer can have multiple ports open;
>

Our current abstraction is designed so each LoadBalancer instance can only
balance across members on a single port.

Changing this would require pretty major changes to the loadbalancer API.

Looking at the other provider APIs, a single balancer instance supporting
balancing across members on multiple ports also doesn't seem like a common
use case so I don't think it fits into Libcloud (I'm still open to
suggestions though and someone could possible convince me otherwise).

Keep in mind that Libcloud is by definition a lowest common denominator
which means we need to sacrifice some not-so-common functionality to make an
API which works with a lot of providers.



> Brightbox servers don't necessarily have a public IP (they can be
> attached to a load balancer without one);


Your implementation could for example subclass base "Member" class[1] and
implement constructor in a way so it only takes a single argument - node id.

Implementing "balancer_attach_compute_node" and
"balancer_dettach_compute_node"[2] also shouldn't be too bad.

In the base driver implementation this method just reads the first public
address from the Node object when constructing a Member object. Your driver
could override those two methods and make them read Node object id when
creating a Member object.


> and the ports for Brightbox
> servers behind a load balancer have to be the same (the port mapping
> is specified on the load balancer).
>
> I'm unsure how to tackle this. Is it possible to generalise the
> libcloud load balancer abstraction to support the Brightbox API
> somehow?
>
> Cheers,
> Tim
>

[1]:
http://libcloud.apache.org/apidocs/0.5.2/libcloud.loadbalancer.base.Member.html
[2]:
http://libcloud.apache.org/apidocs/0.5.2/libcloud.loadbalancer.base.Driver.html#balancer_attach_compute_node

Re: [dev] Brightbox load balancer support

[Roman Bogorodskiy <bo...@gmail.com>]

  Tim Fletcher wrote:

> Hi folks,
> 
> I've been trying to add support for the [Brightbox load balancer
> API][1] to libcloud, and there's a bit of a mismatch between the two
> models.
> 
>   [1]: https://api.gb1.brightbox.com/1.0/#load_balancer
> 
> From what I can tell from reading through the code, the libcloud model
> is that a load balancer has a public IP, a single port number, and it
> balances traffic between multiple "members" (i.e. servers), each of
> which has a public IP and a single port number. Is that correct?

Yes, this is correct.

> There are several key differences between this and the Brightbox
> model: a Brightbox load balancer can have multiple ports open;
> Brightbox servers don't necessarily have a public IP (they can be
> attached to a load balancer without one); and the ports for Brightbox
> servers behind a load balancer have to be the same (the port mapping
> is specified on the load balancer).
> 
> I'm unsure how to tackle this. Is it possible to generalise the
> libcloud load balancer abstraction to support the Brightbox API
> somehow?

I think it's possible to fit that into libcloud model.

It's not a problem that servers (or 'members' in libcloud terms) don't
have public IPs, as when you add a new member you pass a member object
to load balancer, not an IP address.

As for multiple ports per balancer it's a little bit harder, but doesn't
seem to be hard to solve as well. We have to options:

- keep current API and represent single Brightbox load balancer with
  multiple ports as a set of load balancers for every single port
  (that's how things are represented for Rackspace balancers for
  example)

- modify API to support multiple ports for a single load balancer, need
  to look if it's possible to do with keeping API backwards compatible.

Roman Bogorodskiy