loadbalancer design now -> code sprint early next week
Adrian Cole
I'd like for us to wrap up our loadbalancer api as soon as we can,
hopefully before the end of the month. Part of this is getting the
abstraction right. I've started work recently on Rackspace
CloudLoadBalancers, which is very close to the abstraction being
defined in OpenStack. There's also an abstraction in CloudStack as
well one being defined in Deltacloud. I'm hoping we can sketch out
design details on a wiki, and then get a code sprint together early
next week.
* Design
- in order to support multiple types of loadbalancers, we may need
to change our model a bit. For example, we will need the ability to
assign pool members via ip/port, in case they were not started via a
computeservice. Moreover, we need a bit more detail in our spec,
likely including at least Members (those receiving traffic),
VirtualIPs, and make a decision whether or not to support multiple
Listeners on the LoadBalancer. Following that, it would be sane to
define distribution models and traffic types, even if these are
literally strings.
- research should include a review of the CloudStack, OpenStack,
and Deltacloud abstractions, any providers we currently support (ex.
aws, gogrid, trmk), and the ones we haven't gotten to, yet (ex.
softlayer)
* Coding
- The coding of the abstraction includes taking our existing one
and changing the model, hopefully to be stub-testable along the way
- Also there's binding of our apis and providers to the
loadbalancer interface, currently only elb is along the way here.
- Finally, there could include fleshing out apis we don't yet
support (ex. softlayer, trunk version of deltacloud, some LB appliance
like Radware)
This plan is just to get us thinking, so feel free to improve upon it.
If you are interested and can help, please do speak up. Design can
start now via email or otherwise (hopefully logged in a wiki). Code
independent of design obviously can start now, and those who don't
mind shifting sands can code to the existing loadbalancer api to give
it a try.
Looking forward to this!
-Adrian
Notes:
jclouds code
* initial abstraction is in loadbalancer
* code that needs a little work for ELB is in sandbox-apis/elb,
sandbox-providers/aws-elb
* beginning and working rackspace code is providers/cloudloadbalancers-us
* other LB code is in providers/gogrid, sandbox-apis/cloudstack, and
arguably in providers/trmk-* (depending on what you decide LB is :) )
* sandbox-providers/softlayer will support both hardware and
software loadbalancers, but the driver is really early days
* apis/deltacloud doesn't support loadbalancers, yet, but it seems
there's discussions on their mailing list
difference in the existing Rackspace vs OpenStack version
* single vip/lb
* want to reference existing vips by address, not id
* removed draining status/condition
* separated out weight as independent from round robin
* disallow updating of protocol/port
* has usage report function, but only bytes in/out
* removed access control as an explicit function (defer to global services)
* only support LEAST_CONNECTIONS and ROUND_ROBIN by default
Adrian Cole
help update this!
http://code.google.com/p/jclouds/wiki/LoadBalancerDesign
Cheers,
-Adrian