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 <[email protected]>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> >
