Re: [DISCUSS] Trove API promotion into jclouds from jclouds-labs-openstack

[Andrew Phillips <ap...@qrmedia.com>]

> And let me finish with a question (or two). Is there strong agreement in the
> community that jclouds should very much emphasize (and restrict core) to APIs
> with cloud-agnostic abstraction layers?

I think we're learned over the years that premature abstraction is  
dangerous, especially in the area of new cloud service types and  
especially where there are initially only one or two examples to go on.

There are two levels of APIs in jclouds, however: the "top-level"  
abstractions compute, blobstore etc. and the things in the "apis"  
directory. Some of these, e.g. route53, don't implement any of the  
top-level abstractions, and so far this hasn't been a problem, from  
what I can see.

There was a similar discussion related to Chef [1] shortly before the  
ASF move, during which there also was tentative agreement on making  
Chef a "core" API without a corresponding top-level abstraction.

I don't see why Trove and RDS couldn't follow Route53, with a  
top-level abstraction being added once we have sufficient APIs and  
providers to choose from.

I should add that this, to me, is very much an orthogonal concern from  
stability and maintenance of the API itself: I fully share Matt's  
feeling that APIs should be stable, well-tested and well-supported  
before becoming part of the main jclouds project.

@Everett: assuming you can share this information, do you have any  
details on anyone outside Rackspace using jclouds with Trove?

ap

[1] https://groups.google.com/forum/#!msg/jclouds-dev/AUCJoNrPD7M

Re: [DISCUSS] Trove API promotion into jclouds from jclouds-labs-openstack

[Everett Toews <ev...@RACKSPACE.COM>]

On Jul 29, 2013, at 5:56 PM, Andrew Phillips wrote:

> I think we're learned over the years that premature abstraction is dangerous, especially in the area of new cloud service types and especially where there are initially only one or two examples to go on.
> 
> There are two levels of APIs in jclouds, however: the "top-level" abstractions compute, blobstore etc. and the things in the "apis" directory. Some of these, e.g. route53, don't implement any of the top-level abstractions, and so far this hasn't been a problem, from what I can see.
> 
> There was a similar discussion related to Chef [1] shortly before the ASF move, during which there also was tentative agreement on making Chef a "core" API without a corresponding top-level abstraction.
> 
> I don't see why Trove and RDS couldn't follow Route53, with a top-level abstraction being added once we have sufficient APIs and providers to choose from.

Agreed.

> I should add that this, to me, is very much an orthogonal concern from stability and maintenance of the API itself: I fully share Matt's feeling that APIs should be stable, well-tested and well-supported before becoming part of the main jclouds project.

Zack did a great job of testing it and I think I covered the well-supported bit in my other email. ;)

> @Everett: assuming you can share this information, do you have any details on anyone outside Rackspace using jclouds with Trove?

Not that I'm aware of. I'll see what I can do about starting to collect stats on this sort of stuff.

Everett

Re: [DISCUSS] Trove API promotion into jclouds from jclouds-labs-openstack

[Matt Stephenson <ma...@mattstep.net>]

Mostly orthogonal, the point where the concerns intersect is that we've
tossed around the idea of creating an abstraction.  That could certainly
drive some changes in both Trove and RDS.  Otherwise, agreed.


On Mon, Jul 29, 2013 at 3:56 PM, Andrew Phillips <ap...@qrmedia.com>wrote:

> And let me finish with a question (or two). Is there strong agreement in
>> the
>> community that jclouds should very much emphasize (and restrict core) to
>> APIs
>> with cloud-agnostic abstraction layers?
>>
>
> I think we're learned over the years that premature abstraction is
> dangerous, especially in the area of new cloud service types and especially
> where there are initially only one or two examples to go on.
>
> There are two levels of APIs in jclouds, however: the "top-level"
> abstractions compute, blobstore etc. and the things in the "apis"
> directory. Some of these, e.g. route53, don't implement any of the
> top-level abstractions, and so far this hasn't been a problem, from what I
> can see.
>
> There was a similar discussion related to Chef [1] shortly before the ASF
> move, during which there also was tentative agreement on making Chef a
> "core" API without a corresponding top-level abstraction.
>
> I don't see why Trove and RDS couldn't follow Route53, with a top-level
> abstraction being added once we have sufficient APIs and providers to
> choose from.
>
> I should add that this, to me, is very much an orthogonal concern from
> stability and maintenance of the API itself: I fully share Matt's feeling
> that APIs should be stable, well-tested and well-supported before becoming
> part of the main jclouds project.
>
> @Everett: assuming you can share this information, do you have any details
> on anyone outside Rackspace using jclouds with Trove?
>
> ap
>
> [1] https://groups.google.com/**forum/#!msg/jclouds-dev/**AUCJoNrPD7M<https://groups.google.com/forum/#!msg/jclouds-dev/AUCJoNrPD7M>
>