Open Stack

On Mon, 2012-11-05 at 12:17 -0800, John Dickinson wrote:
> On Nov 5, 2012, at 12:12 PM, Mark McLoughlin <markmc at redhat.com> wrote:
> 
> > On Mon, 2012-11-05 at 14:33 -0500, Jay Pipes wrote:
> >> On 11/02/2012 12:56 PM, Mark McLoughlin wrote:
> >>> My opinion - the GCE work looks awesome, it's an exciting new feature
> >>> and it's the kind of awesome new feature by awesome developers that we
> >>> should be facilitating.
> >>> 
> >>> We have a long term goal of facilitating work like this happening
> >>> outside of Nova, but no real sign of that goal coming about in the
> >>> medium term.
> >>> 
> >>> We shouldn't let our idealistic long term plans get in the way of
> >>> pragmatic, exciting progress happening now.
> >> 
> >> Yeah, I mostly agree with what you're saying above and in the rest of
> >> the post. That said, however, the rub is that while the GCE work looks
> >> awesome, this whole topic came up, IIRC, because of the OCCI-compatible
> >> work that had been proposed. I personally didn't care for the OCCI work
> >> and didn't want it in Nova core.
> > 
> > What was the issue with the OCCI work? I don't recall ever seeing a
> > patch
> 
> The main issue (along with the CDMI patch in Swift) was one of support
> and maintenance. The CDMI patch (would have) added a significant
> amount of code, significant complexity, and the core devs and other
> contributors weren't familiar enough with the spec or uses to be
> willing to accept responsibility of maintaining it or even properly
> reviewing it.

In the case of GCE, we'd be welcoming a group of developers to the Nova
developer community and that group would be responsible for a
significant amount of its maintenance. We shouldn't welcome any "toss it
over the wall" style feature patches.

Frankly, I'm more concerned about the support and maintenance burden of
something like the bare-metal driver currently under review for Nova.

In terms of support and maintenance, I don't see an API being all that
different from any other new proposed feature.

Mark.