> > 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
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
