Open Stack

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