Open Stack

On Wed, Dec 11, 2013 at 9:35 AM, James Slagle <james.slagle at gmail.com>wrote:

> On Wed, Dec 11, 2013 at 7:33 AM, Jiří Stránský <jistr at redhat.com> wrote:
> > Previously, we had planned Tuskar arcitecture like this:
> >
> > tuskar-ui <-> tuskarclient <-> tuskar-api <-> heat-api|ironic-api|etc.
>
> To be clear, tuskarclient is just a library right?  So both the UI and
> CLI use tuskarclient, at least was that the original plan?


I would expect tuskarclient above to be the Python API bindings without the
business logic.


> I don't think we want the business logic in the UI.


+1


> > Now this raises a question - how do we get CLI reasonably on par with
> > abilities of the UI? (Or am i wrong that Anna the infrastructure
> > administrator would want that?)
>
> IMO, we want an equivalent CLI and UI.  A big reason is so that it can
> be sanely scripted/automated.


At a minimum you need to be sure that all of the atomic operations in your
business logic are exposed via _some_ API.  ie, to script something the
script may be where the business logic exists.

Building on that is moving that logic into a library that calls multiple
Python client APIs.  This may or may not be part of tuskarclient.

The next step up is to put your business logic into what we used to call
middleware, the layer between client and backend.  This is server-side and
IMHO where it belongs.  This is really the ONLY way you can ensure that
various clients get the same experience.


> python-openstackclient consumes other clients :).  Ok, that's probably
> not a great example :).
>

:) No, not really.  But it is also developing some 'value-added' functions
that are cross-project APIs and has a similar problem.  So far that is just
smoke and mirrors hiding the duck tape behind the scenes but it is not
unlike some of the things that Horizon does for user convenience.


> This approach makes the most sense to me.  python-tuskarclient would
> make the decisions about if it can call the heat api directly, or the
> tuskar api, or some other api.  The UI and CLI would then both use
> python-tuskarclient.


If you do this keep the low-level API bindings separate from the
higher-level logical API.


> > 2) Make a thicker tuskar-api and put the business logic there. (This is
> the
> > original approach with consuming other services from tuskar-api. The
> > feedback on this approach was mostly negative though.)
>
> So, typically, I would say this is the right approach.  However given
> what you pointed out above that sometimes we can use other API's
> directly, we then have a seperation where sometimes you have to use
> tuskar-api and sometimes you'd use heat/etc api.  By using
> python-tuskarclient, you're really just pushing that abstraction into
> a library instead of an API, and I think that makes some sense.


Consider that pushig out to the client requires that the client be in sync
with what is deployed.  You'll have to make sure your client logic can
handle the multiple versions of server APIs that it will encounter.
 Putting that server-side lets you stay in sync with the other OpenStack
APIs you need to use.


> > 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? :) )
>
> I don't follow how this new library would be different from
> python-tuskarclient.  Unless I'm just misinterpreting what
> python-tuskarclient is meant to be, which may very well be true :).


This is essentially what I suggested above.  It need not be a separate repo
or installable package, but the internal API should have its own
namespace/modules/whatever.

dt

-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131211/4e136907/attachment.html>