Actually, we've had a fair amount of corporate-backed provider work, but a lot of it has been fire-and-forget - a provider either doing the initial work themselves or contracting it out, getting it added to jclouds (or labs) and then...vanishing. I can see a lot of that floating around, and I'm guessing that's part of Matt's wariness.
A. On Mon, Jul 29, 2013 at 3:28 PM, Matt Stephenson <[email protected]>wrote: > "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 > > >>>> > > >>> > > >> > > > > >
