Open Stack

Jarret Raim  wrote:

>>I'm presuming that this is our last opportunity for API review - if
>>this isn't the right occasion to bring this up, ignore me!
>
> I wouldn't agree here. The barbican API will be evolving over time as we
> add new functionality. We will, of course, have to deal with backwards
> compatibility and version as we do so.

I suggest that writing bindings for every major language, maintaining
them through API revisions, and dealing with all the software that
depends on your service is a much bigger undertaking than e.g. writing
Barbican itself ;-)  So it seems much more efficient to get v1 closer
to right.

I don't think this need turn into a huge upfront design project
either; I'd just like to see the TC approve your project with an API
that the PTLs have signed off on as meeting their known needs, rather
than one that we know will need changes.  Better to delay take-off
than commit ourselves to rebuilding the engine in mid-flight.

We don't need the functionality to be implemented in your first
release, but the API should allow the known upcoming changes.

> We're also looking at adopting the
> model that Keystone uses for API blueprints where the API changes are
> separate blueprints that are reviewed by a larger group than the
> implementations.

I think you should aspire to something greater than the adoption of Keystone V3.

I'm sorry to pick on your project - I think it is much more important
to OpenStack than many others, though that's a big part of why it is
important to avoid API churn.  The instability of our APIs is a huge
barrier to OpenStack adoption.  I'd love to see the TC review all
breaking API changes, but I don't think we're set up that way.

Justin