When we do have a new API that doesn't have any equivalents, then yeah, promoting on its own seems OK. But then when sibling APIs come along down the road, for them to get promoted, there'll need to be an abstraction added, I'd say. Does that make sense?
A. 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 > >>>> > >>> > >> > >
