incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Bogorodskiy <>
Subject Re: [libcloud] Load Balancers support
Date Wed, 06 Apr 2011 19:27:51 GMT
  Tomaz Muraus wrote:

> Glad to see some new code and ideas flying in :)
> Here are some of my comments and concerns:
>    - I have already posted this in my previous email, but imo we need a
>    special place to put all those extra resources such as load balancers in.
>    I don't think having a separate top-level module is acceptable, because
>    there are many more resources we can implement, but most of them
>    are relatively small compared to the compute and the storage API.
>    We should probably move those resources to *
>    libcloud.resources.{loadbalancer,ip,foobar}* or something like this?

Makes sense.

>    - We should also limit which resources we will support and implement
>    based on the number of providers which support them - e.g. if there are less
>    than 3 providers, we shouldn't support it.

Load Balancers service is quite a common offering now.

>    - I would vote to also research Amazon and GoGrid load balancer
>    implementations before deciding how the final interface should look like,
>    because there is a huge chance that your interface is currently biased
>    towards the Rackspace API.

I've closely looked at GoGrid balancers before starting an
implementation. Actually, I was going to start with GoGrid driver first,
but it happened that I need Rackspace balancers more currently. I think
the abstraction used for balancers is more or less OK and wouldn't
require major modifications for the new drivers.

I had a brief look at balancing service at Amazon and the object model
they use is almost the same, but they expose this as WSDL, not REST.

Unfortunately, I don't have neither need to use Amazon balancers nor
possibility to have an account there (they don't accept my credit card
for my reason).

>    - I will post some code comments in-line on github later on. In general
>    it looks OK, but there are some minor styling issues, missing __ALL__
>    statements and a few places with a repeated code.


>    - Tests - yeah, for the new things we should aim for a test coverage of
>    95% and above.

Coverage of 95% is too strict in my opinion, esp. considering that most
features are very easy to test at runtime. I think a rule of thumb that
all major components should be covered with test without going with
exact numbers etc.

Thanks for feedback,

Roman Bogorodskiy

View raw message