openstack team mailing list archive

[Justin Santa Barbara <justin@xxxxxxxxxxxx>]

>
> If EC2 API is limiting what we can do, that's not going to change just
> because you move the EC2 API implementation into a proxy in front of the
> OpenStack API. The only difference is that it's suddenly the AWSOME
> development team's problem.
>

I think it's actually the EC2 API caller's problem.  It's easy to map a
subset to a superset, but you can't cover the superset with the subset.
 Suppose Quantum defines e.g. Layer 2 security groups, which I think has no
parallel in EC2.  If you want to use L2 security groups, you'd have to use
the OpenStack API.

A nice AWSOME developer might treat it as their problem, but it's not
really.

> With one native API, we can focus all our energies on making sure that API
> > works.  Then, knowing that the native API works, we can build other APIs
> on
> > top through simple translation layers, and they will work also.  Other
> APIs
> > can be built on top in the same way (e.g. OCCI)
>
> Sorry, I'm having trouble here.. Are you suggesting that having two
> sibling frontend API's talking to a shared backend API is poor software
> engineering, but layering similar purposed API's on top of each other
> like this is good software engineering?


Obviously not when you put it like that :-)

The difference that I see is whether the 'service' layer is documented and
kept stable (i.e. subject to API evolution rules).  Right now, we do that
work for the OpenStack API only.

I think it's great if someone is going to document and stabilize our
internal APIs.  However, unless you're willing to do it personally, I don't
think anyone should assume it'll be done.

So my viewpoint is that, while it would be great to have interface
contracts on all our internal interfaces, I'll believe it when I see it.
 Until then, we have one stable interface, and so using that stable
interface as the service layer seems like a sensible approach.

I can see us using ProtocolBuffers or JSON schema for messages that go over
the message bus, maybe even in Folsom.  I can't see us locking down the
other code interfaces before we give up on this Python thing and port to
Java, i.e. it's not going to happen.

Actually, I think JSON schema for our message-bus messages might be a
really good idea (tm).  Violations could just be warnings until we get
things locked down... maybe I should propose a blueprint? (Although I have
enough of a blueprint backlog as it is...)

Justin