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 > > >>>>>> > > >>>>> > > >>>> > > >> > > >> > > > > >
