I think the most important things to take into account when promoting an API to the main repo should be: * Having someone committed to maintain and support it (not only with code, also with documentation and being active in the mailing list). * Being mature enough and used by someone. * There should be a public endpoint or something we could run the live tests against.
The first point is what we learned from previous mistakes, and I think Rackspace is doing a great job with their providers. They've written the more complete examples and a good documentation (something many providers are missing), and are active in the mailing list and in code contributions. And the most important thing, they're going to keep doing like this. The second one is, IMO, the tricky one, because there hasn't been any user request to promote the Trove API out of labs. I'm not sure if it is being used or if it is mature enough, but I also agree with Everett that APIs become mature once they are adopted, and promoting Trove out of labs may help that adoption. If promoting it out of labs means that more people will use the API and the community will grow, then I think it is good to promote it. I don't think having an abstraction should be a requirement to promote an API out of labs. As Andrew P. said, abstractions can be added once a second API appears, and I think that might be better, since adding them in a too early stage may end up in a worse design. (This does not invalidate what Andrew B. suggested to start working on a DB abstraction, which I think it would be good). In conclusion, my main concern about promoting an API is to be sure that it will be maintained, evolved, bugfixed, and that it won't block us when releasing (this is a consequence of the previous points and the most important one IMO), and I think Trove meets all these requirements. My two cents! On 30/07/2013, Matt Stephenson <[email protected]> wrote: > Yeah, I would rank another abstraction being added to jclouds as a massive > contribution of epic proportion. Once there is some critical mass, I'm > sure there will be interest from Google to jump on this. > > Matt > > > On Mon, Jul 29, 2013 at 6:11 PM, Andrew Bayer > <[email protected]>wrote: > >> It wouldn't be a bad idea to start at least some design work on a DB >> abstraction layer in the meantime - and hey, you guys get to define the >> abstraction in terms of Trove, since it's the one that's actually here >> and >> ready anyway. =) >> >> A. >> >> On Mon, Jul 29, 2013 at 5:53 PM, Everett Toews >> <[email protected]>wrote: >> >> > 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 >> > >>>>>> >> > >>>>> >> > >>>> >> > >> >> > >> >> > >> > >> >
