That makes sense. In the case of APIs with equivalents, I'm still concerned about how long it could take (if ever) for a sibling API implementation to come along down the road though.
In Trove's case, there's a (partial?) RDS implementation already in jclouds-labs-aws. Perhaps it will get polished up or maybe someone will come along and provide support for Google Cloud SQL. It seems like a possibility so I'm willing to wait with Trove in jclouds-labs-openstack and see how this plays out. Everett On Jul 29, 2013, at 5:27 PM, Andrew Bayer wrote: > 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 >>>>>> >>>>> >>>> >> >>
