On Wed, 2013-12-11 at 09:32 -0500, Jay Dobies wrote: > On 12/11/2013 07:33 AM, Jiří Stránský wrote: > > 3) Keep tuskar-api and python-tuskarclient thin, make another library > > sitting between Tuskar UI and all python-***clients. This new project > > would contain the logic of using undercloud services to provide the > > "tuskar experience" it would expose python bindings for Tuskar UI and > > contain a CLI. (Think of it like traditional python-*client but instead > > of consuming a REST API, it would consume other python-*clients. I > > wonder if this is overengineering. We might end up with too many > > projects doing too few things? :) ) > > This is the sort of thing I was describing with the facade image above. > Rather than beefing up python-tuskarclient, I'd rather we have a > specific logic layer that isn't the CLI nor is it the bindings, but is > specifically for the purposes of coordination across multiple APIs. > > That said, I'm -1 to my own facade diagram. I think that should live > service-side in the API.
And this is what Dean said should be implemented as WSGI middleware, which I agree is likely the most flexible and architecturally-sound way of doing this. Best, -jay _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
