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. Ok. > - 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
signature.asc
Description: Digital signature
