[dev] 0.6 Roadmap

[Paul Querna <pa...@querna.org>]

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.

- 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)

- 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.

- 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/> ?

Thoughts? Other features?

Thanks,

Paul

Re: [dev] 0.6 Roadmap

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

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 <pa...@querna.org> 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
>

Re: [dev] 0.6 Roadmap

[Jed Smith <je...@jedsmith.org>]

Responses inline.

On Sat, Jun 4, 2011 at 8:35 PM, Paul Querna <pa...@querna.org> wrote:
> - 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. It's an extremely simple abstraction, too, in my mind. I have an idea for
how it should work which I will discuss separately.

> - 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)

+1 to too early.

> Thoughts? Other features?

You brought it up lightly and my only feedback would be this: I feel like
libcloud 1.0 should be Python 3 compatible. I can't give a good reason for that
beyond "it feels right", and maybe it isn't the right time, that's just how I
feel about it. Maybe we 2to3 properly as well, I haven't tried.

JS