I can certainly understand that perspective. It was common knowledge in our pre-Apache state but let me mention it again here.
Rackspace is 100% committed to the continued development, maintenance, and support of jclouds and fostering our community. jclouds is the Java SDK for the Rackspace Cloud. We had a couple of "single product" Java SDKs in the past but they were deprecated in favor of jclouds. It would be great to see other cloud providers step up and make similar commitments. I'm hoping our involvement can provide the impetus for this and continue to grow our community. *gets off soapbox* Regards, Everett On Jul 29, 2013, at 5:47 PM, Andrew Bayer wrote: > 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 >>>>>>> >>>>>> >>>>> >>> >>> >>
