"doomed" is a bit extreme. Let me repeat : There are labs apis that are used by our users. Typically it's user-pressure that pushes APIs out of labs. Being in labs has not historically prevented people from using something.
We're volunteers on a community driven project, it's not about one person or another, it's about the project. Most of these providers have historically not had any corporate backing, so this is a first for our community. Rackspace is certainly putting forth more resources than I've ever seen a company put forth on jclouds. On Mon, Jul 29, 2013 at 2:59 PM, Everett Toews <[email protected]>wrote: > Of course I'm on board with providing portable abstractions. > > At this point, my primary concern is what happens when we have an API that > has no sibling APIs? > > Either because that API is unique to a cloud provider or no one has > implemented support for that API in another cloud provider. The effect is > the same. We don't have multiple APIs to base a portable abstraction on > yet. I also don't think it's reasonable to expect someone from Rackspace or > Google to implement an API for AWS. > > The jclouds definition goes on to say, "The jclouds API gives you the > freedom to use portable abstractions or cloud-specific features." > > jclouds has never dictated that you must use the portable abstractions. > It's always been about the freedom to do both. I emphasize this in my > presentations about jclouds. Developers need to be taught that they must > take care to write their code to the abstractions for maximum portability. > But if those abstractions don't meet their requirements, they can use > specific features. Use the best tool for the job. > > An API should not be doomed to forever be in labs just because it has no > sibling API and hence no chance for there to be a portable abstraction. > > Everett > > On Jul 29, 2013, at 4:29 PM, Matt Stephenson wrote: > > > "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 > >>>> > >>> > >> > >
