Which actually reminds me, I should open JIRAs for DNS/loadbalancer abstractions...
A. On Mon, Jul 29, 2013 at 1:24 PM, Matt Stephenson <[email protected]>wrote: > 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 > > > > > >
