Open Stack

23. apr. 2012 17.15 skrev Justin Santa Barbara <justin at fathomdb.com>:
>> What's the advantage of replacing the native EC2 compatibility layer with
>> AWSOME from a user / operator point of view?
> Although I wasn't able to attend the design summit session, right now we
> have two "native" APIs, which means we have two paths into the system.

Yes. This is good. It keeps the layers of separation "honest". Multiple
consumers of internal API's helps in making it more obvious at which
layer functionality belongs. Just like having multiple hypervisor
drivers (at least supposedly) makes it more obvious what sort of stuff
belongs in the drivers and what sort of stuff belongs in the compute
manager.

> That is poor software engineering, because we must code and debug
> everything twice.

I beg to differ. If we need to fix things twice, it's because we've
violated the layers of separation somewhere. For the record, I'm
fully prepared to believe that we've done so. I also fully believe that
the fact that we haven't done so *more* is because we have two API's to
consider. Eric Day went through all the calls from the frontends into
the various backend managers a long time ago, ensuring this separation
was clear. I'm convinced that the result was a massive improvement.

> Some developers will naturally favor one API over the other, and so
> disparities happen.  Today, both APIs are effectively using an
> undocumented private API, which is problematic.

Yes. This is a problem. However, as I understand it, there was a session
at the summit about versioning the internal API's. I'm not sure how we
can usefully version the API's without also documenting them, so that
problem should be adressed in the relatively near future.

> We also can't really extend the EC2 API, so it is holding us back as
> we extend OpenStack's capabilities past those of the legacy clouds.

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.

> 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?

-- 
Soren Hansen             | http://linux2go.dk/
Senior Software Engineer | http://www.cisco.com/
Ubuntu Developer         | http://www.ubuntu.com/
OpenStack Developer      | http://www.openstack.org/