Hello, Yes, as part of the graduation I also wanted to define some kind of official road-map which would be published on the website.
I have posted my opinion about your suggestions in-line. On Sun, Jun 5, 2011 at 2:35 AM, Paul Querna <[email protected]> wrote: > Hiya All, > > I figure we should get the ball rolling on what we would all like to > see in 0.6 for Libcloud (maybe it could be called 1.0 too, but its > probably best to have that discussion separately) > > My thoughts so far: > > - DNS API: Amazon, Linode, Zerigo, Slicehost, etc all have DNS > management APIs. Combining the management of Load Balancer with DNS > seems like the next logical step. > +1, I also think DNS is the next logical step after storage and load-balancers. > - Monitoring API: Amazon Cloudwatch and Cloudkick both provide APIs > for monitoring instances; I'm not sure we can actually get a good > abstraction here yet, maybe it is too early. (And full disclaimer, I > work at Cloudkick) > Yes, I am not sure if we can actually create a good and useful abstraction for monitoring services. There are many of them (Cloudkick, Amazon Cloudwatch, ServerDensity, Librato Silverline, New Relic, etc.) and they focus on different things. For example, New Relic mostly focus on application specific metrics whereas Amazon Cloudwatch mostly focus on server specific ones. In any case, even if we can't come up with something useful yet, I still think we should explore this space and maybe even develop some prototypes. > - Revamp of Locations & Regions: I believe for the compute API its > obvious the mix of having a Driver for different region, or sometimes > the list_locations API is less than ideal. I think a related issue is > the pain it is to point a driver at a custom endpoint URL, which will > become more common as things like OpenStack Nova instances get stood > up by more companies. > How do you think we should handle locations? The main problem is that in some providers (e.g. Rackspace), locations are totally separated and you even need a different account / set of credentials for another location. > - Improve non-python access to Libcloud: Maybe this means we could > adopt the provide a REST api that DeltaCloud supports, or maybe just > bundling something like lctools <http://novel.github.com/lc-tools/> ? Hmm, I'm not totally sure if something like this should be part of the core. I think it would be nice if someone would create a library which exposes libcloud functionality over HTTP, but I don't want to re-invent DeltCloud either :) Maybe we should contact DeltaCloud team and see if we can some how cooperate? > Thoughts? Other features? > My primary goal for the next version would also be to include more provider drivers for the Storage and Load balancer APIs. If anyone is willing to work on a new provider driver, let us know so we can provide guidance if needed. There are some low-hanging fruits such as Google Storage driver which should be pretty easy to implement, because it mimics S3 API and IIRC the only difference is the actual authentication process. > Thanks, > > Paul >
