Open Stack

On Mon, 2012-11-05 at 14:43 -0600, Anne Gentle wrote:
> Regarding the scope clarification - my question is, is the TC making
> policy that all -core projects must follow?

No, we're just asking the TC to recognize that Nova isn't ready to meet
the requirements necessary to follow the PPB's previous aspirational
direction and allow us to accept further 3rd party APIs.

> If so, then we will need detailed definitions of what it means to
> accept an API - code patches and reviews seem to be assumed but what
> about test platforms? Minimum documentation?

Does this differ from other features? Do we have detailed definitions of
what nova-core must require before it can accept a new virt driver?

> > In terms of support and maintenance, I don't see an API being all that
> > different from any other new proposed feature.
> 
> Specifically, I don't think this is true - testing, releasing, and
> documenting are all part of this support and maintenance. I don't
> think we'll get the doc and test support we'd need based on what I've
> observed so far with the Swift 3rd-party APIs - configuring how-tos
> for S3 for example weren't put into the documentation. I also realize
> that certain features are not being documented fully (the bare metal
> stuff has me concerned as well).

Again, not seeing the support and maintenance difference between
features generally and APIs specifically.

> What I think inclusion of more APIs, what it does is put more burden
> on prioritizing - what do we document first? second? third? And so on.

The kind of APIs being proposed have an interesting property that other
new features don't have - they generally will have existing developer
documentation.

e.g. we don't really have much in the way of documentation for Nova's
EC2 implementation AFAIK, but I assume developers lean heavily on EC2's
own great documentation.

> My questions relate to: beyond just the patch acceptance, what are we
> signing (all projects) up for? It's not a matter of blocking but
> wondering how to resource honestly so we can sign up for this in good
> faith (pragmatically not visionarily). Just made that last word up.

Certainly happy to discuss that generally in the context of accepting
any large new feature into any project but it seems like something we've
largely left up to the individual PTLs to decide up until now.

Again, I have some concerns about what we're signing up to with the
bare-metal driver but, in the end, it currently falls on Vish to make
that call.

Cheers,
Mark.