Ugh, sorry, burned again by outlook web. Let me continue ...

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()

What's the real win here?

I agree that the heavy lifting logic should be removed from the os/ec2 api 
layers and only be doing parameter checking ... but they may also do 
mapping/translations to the underlying service api's.

Perhaps the issue is that the lower level (nova.[service].api) doesn't have a 
formal enough definition and is getting pulled in two directions by ec2/os api? 
Perhaps making this layer have a clear contract is what we're missing?

-S



________________________________
From: Lorin Hochstein [[email protected]]

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     : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to