On Jul 8, 2011, at 10:36 AM, Sandy Walsh wrote:
> +1 to Soren's argument that ec2 is the 1000lb gorilla and should be central
> to nova. We definitely need to support it with as close to 100% compatibility
> as we can.
>
> Sounds like the only option is to "embrace and extend" it. Do everything it
> can do, and layer on what we need provided it doesn't break the core EC2
> commands. If the customer wants pure EC2, they'll have to live with the
> limitations.
>
> That said, is this the proposal I'm hearing? ...
>
> Since our separation is done at the service.api layer, the service.api's get
> pulled in two directions with each change in ec2/os. The idea is to have ec2
> be a translation layer to os api? Preventing ec2 api from calling
> [service].api directly?
>
> So, instead of
>
> EC2 Client OS Client
> | |
> EC2 API OS API
> \ /
> [Service] API
>
> We'd be shifting to:
>
> EC2 Client ---- EC2 API
> |
> OS Client ------ OS API
> |
> [Service] API
>
> I need to think more about this, but at first blush, it doesn't seem like
> such a [bad] thing? At some point the abstraction layer needs to be locked
> down doesn't it?
>
I think it actually looks more like this right now:
EC2 Client OS Client
| |
EC2 API OS API
\ /
[nova-*] service APIs
There isn't really a single back-end API for the front-end APIs to call into.
Instead, each of them makes calls to the multiple service APIs (e.g.,
scheduler, network, compute).
I would advocate for something more like this:
EC2 Client OS Client
| |
EC2 API OS API
\ /
internal nova API
|
[nova-*] service APIs
This is a single, unified API that is meant only for internal use. This would
reduce the coupling between front-end and back-end. It would make it easier for
someone with less expertise in the code (hello!) to find the location in the
code that answers questions like: "What does nova do when a user requests that
an instance is launched?" They would just look at the internal API and find
the appropriate method. It would also make it easier to add additional
front-ends, if there's ever any interest in that.
Lorin
--
Lorin Hochstein, Computer Scientist
USC Information Sciences Institute
703.812.3710
http://www.east.isi.edu/~lorin
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
