On Jul 11, 2011, at 9:23 AM, Sandy Walsh wrote: > 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 was initially confused by the self.compute_api.create call in the nova/api/ec2/cloud.py:CloudController.run_instances method. I think my source of confusion was: why is the compute API being called directly, shouldn't the scheduler do this? (I didn't realize at the time that this leads to a scheduler request). Would pushing this down one layer have helped me understand this better? In retrospect, maybe not... > 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? > Yeah, I'm not sure what the best solution is here... Lorin -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin > -S > > > > 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
