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