I'm still stewing on this but at first blush this seems like an artificial
abstraction. What do we really gain from having another layer above the service
api's? Can't they just live at the service api?
For example:
nova.compute.api:create_instance()
vs.
nova.business_layer:create_instance()
________________________________
From: Lorin Hochstein [lo...@isi.edu]
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.
This email may include confidential information. If you received it in error,
please delete it.
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
