openstack team mailing list archive

[Soren Hansen <soren@xxxxxxxxxxx>]

2011/7/7 Vishvananda Ishaya <vishvananda@xxxxxxxxx>:
> On Jul 7, 2011, at 11:35 AM, Soren Hansen wrote:
>> 2011/7/7 Trey Morris <trey.morris@xxxxxxxxxxxxx>:
>>> The goal isn't for ec2 api to be a "second class citizen", but to keep it
>>> from being a limiting factor since we don't have control over it. How does
>>> the compatibility layer make it second class?
>> Well, for one thing because you'll be limiting the EC2 API to what the
>> OpenStack API is capable of doing and/or expressing.
> Actually, we can add any code that is necessary to make the ec2 api work properly as extensions to the os api.

Maybe it's functionality that we don't want anywhere near the OpenStack API?

> My main reason for suggesting the switch over to a compatibility layer is so that we don't have multiple code paths into the heart of nova.

Both frontend types will be speaking to the same backend API. That's
where we translate the user's requests into actions that the backend
can perform. This sounds like a very reasonable split to me. I don't
understand why we'd change that. Building a backend that is reasonably
frontend-API-agnostic is a good thing. It keeps us honest and helps
maintain a clear separation of the various components. Eric did a lot
of excellent work to make this split cleaner. I'd hate it if we
blurred the lines between frontend and backend again.

> This has been a pain point already, and it will only get more painful as we move forward.

IMO, reworking things to achieve looser coupling is tricky and
painful, but time well spent.

> If all the stuff that makes ec2 compatibility work is in one place at the top layer, it is easier to maintain.

I'll see your unsubstantiated claim, and raise you another one: It'll
simply make other parts harder to maintain.

> If we need to maintain entirely disparate code paths from the api all the way down to the hypervisor, things will continue to be very fragile.

It's not at all down the hypervisor. Not even close. The (currently)
two different API frontends will interact with the relevant services
(network, compute or scheduler), all of which should have a
well-defined, flexible API. So far, these API's have been extended on
a very ad-hoc basis to support some new functionality in either of the
frontend API's. Just to be clear: I'm guilty of this too!  What we
should be doing is defining sensiblem coherent API's for these backend
services, document their interfaces and treat them with respect, be
aware when/how they change, attempt to maintain backwards/forwards
compatiblity.  When we start to think about how to upgrade Nova
deployments, this will be very helpful. Having different things
talking to the same API's keeps us more honest in this regard.

So, I feel the exact opposite. A lot of the current fragility of Nova
stems from the fact that we've focused a lot on specific features and
not very much on these grander, more holistic things. When something
is tightly coupled, and you try to bolt something else onto it, yes,
it becomes fragile. Not because you're bolting things on, but because
you didn't consider early enough that other things might be bolted on
further down the road.

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