As a user I would rather have the feature as soon as possible in a stable release; and improvements (such as an abstraction layer) also available as soon as possible. It seems to me there is a trade-off between fast(er) organic growth and following (good) ideological guidelines for keeping jclouds cloud-agnostic. Perhaps there is a way to have your cake and eat it too? Labs might be it but I think Everett has a point that it might preclude faster adoption. I find the extreme of this trade-off in Fedora going for ideological purity while being outpaced by Ubuntu (yes there were many other reasons). :)
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? As goals, how should these be prioritized (this might be going out of scope): ease-of-use, feature-rich, cloud-agnostic? Thanks! ________________________________________ From: [email protected] [[email protected]] on behalf of Matt Stephenson [[email protected]] Sent: Monday, July 29, 2013 3:24 PM To: [email protected] Subject: Re: [DISCUSS] Trove API promotion into jclouds from jclouds-labs-openstack I'm ok with the abstraction being pretty minimal for starters, but that really should be added into jclouds-labs and promoted concurrently with either (or both) trove and RDS. I think you summed up my feelings pretty well Andrew. We're a cloud-agnostic api provider, it makes more sense for us to make sure we're solidly moving that way long-term. On Mon, Jul 29, 2013 at 1:19 PM, Andrew Bayer <[email protected]>wrote: > I personally would like to avoid promoting things to core that aren't > implementations of an abstraction - I know we've got DNS stuff that doesn't > have an abstraction in core, but, again, personally, I don't much care for > that. I'd be in favor of holding off on moving trove from labs->core until > there's a "cloud db" abstraction a la compute/blobstore for RDS/trove to > implement. > > A. > > On Mon, Jul 29, 2013 at 1:13 PM, Matt Stephenson <[email protected] > >wrote: > > > It sounds like a primary motivator is to widen the audience. We have > many > > providers and apis in labs that are more widely adopted. Historically > this > > hasn't been a major barrier to adoption overall. > > > > The goal of labs was to provide a place to release software that we still > > feel is in flux overall. How stable is the overall API for this if we've > > not really done much work on RDS lately to ensure that a unified API > > between the two (long term) is possible without changing the api into the > > trove provider? > > > > > > On Mon, Jul 29, 2013 at 1:08 PM, Everett Toews > > <[email protected]>wrote: > > > > > On Jul 29, 2013, at 2:03 PM, Matt Stephenson wrote: > > > > > > > We currently have an outstanding set of pull requests for this, prior > > to > > > us > > > > discussing this on dev. I'm personally not in favor of promoting it > at > > > > this time because I feel it's a bit too immature at this time. > > > > > > Software gains maturity by being released to a wider audience and by > > being > > > used. And what we have here is more than a minimum viable product. It's > > > complete, working support for the OpenStack Trove/Rackspace Cloud > > Databases > > > API. > > > > > > > We still > > > > have a good deal of other apis that there is more demand for to be > > > promoted > > > > up. > > > > > > It's not an either/or situation amongst the APIs. If an API is > complete, > > > it can be promoted. > > > > > > > What value do we gain by promoting this as the only api of it's kind > > into > > > > jclouds now? > > > > > > We gain a wider audience. We gain the experience of seeing how people > use > > > it and what problems they run into. We gain the insights and experience > > > that are necessary to create higher level abstractions. All of those > > things > > > that helps software mature. > > > > > > Just because an implementation from another provider isn't ready, > doesn't > > > mean we should hold back on releasing software. We need to start > > somewhere. > > > > > > In general, the value of jclouds increases for our users because we'll > > > have complete and maintained support for another cloud API. > > > > > > > Who in the community is using this in labs today? > > > > > > Naturally we (Rackspace) are. There are also examples and doc ready to > > go. > > > Having a "labs" label on something will prevent many from adopting it. > > > > > > > How comfortable are we as a community in supporting this and working > on > > > > issues related to it? > > > > > > I can say with complete conviction that, as a part of this community, > > > Zack, Jeremy, and myself are 100% committed to supporting it and > working > > on > > > issues related to it. > > > > > > Regards, > > > Everett > > >
