"Cloud interfaces, simplified" sums up that yes, we do prefer to keep a simple api that is portable, and has been a goal of the project for as long as I've been a part of it.
This is something that certainly benefits the rackspace community, but I don't see it as beneficial outside of that. This is exactly what labs is for, apis that are not yet ready to be promoted into the primary package build. We've had a long history of trying to name this to avoid turning people off from using it, but I guess we've failed again at that. AFAIK, there are plenty of people using packages in the labs namespace. I don't have the maven central stats on that though. Matt On Mon, Jul 29, 2013 at 2:16 PM, Zack Shoylev <[email protected]>wrote: > 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 > > > > > >
