[openstack-dev] [TripleO] Tuskar CLI after architecture changes

James Slagle james.slagle at gmail.com
Wed Dec 11 15:35:41 UTC 2013

On Wed, Dec 11, 2013 at 7:33 AM, Jiří Stránský <jistr at redhat.com> wrote:
> Hi all,
> TL;DR: I believe that "As an infrastructure administrator, Anna wants a CLI
> for managing the deployment providing the same fundamental features as UI."
> With the planned architecture changes (making tuskar-api thinner and getting
> rid of proxying to other services), there's not an obvious way to achieve
> that. We need to figure this out. I present a few options and look forward
> for feedback.
> 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?

> This meant that the "integration logic" of how to use heat, ironic and other
> services to manage an OpenStack deployment lied within *tuskar-api*. This
> gave us an easy way towards having a CLI - just build tuskarclient to wrap
> abilities of tuskar-api.
> Nowadays we talk about using heat and ironic (and neutron? nova?
> ceilometer?) apis directly from the UI, similarly as Dashboard does.

I think we should do that whereever we can for sure.  For example, to
get the status of a deployment we can do the same API call as "heat
stack-status ..." does, no need to write a new Tuskar API to do that.

> But our approach cannot be exactly the same as in Dashboard's case.
> Dashboard is quite a thin wrapper on top of python-...clients, which means
> there's a natural parity between what the Dashboard and the CLIs can do.
> We're not wrapping the APIs directly (if wrapping them directly would be
> sufficient, we could just use Dashboard and not build Tuskar API at all).
> We're building a separate UI because we need *additional logic* on top of
> the APIs. E.g. instead of directly working with Heat templates and Heat
> stacks to deploy overcloud, user will get to pick how many
> control/compute/etc. nodes he wants to have, and we'll take care of Heat
> things behind the scenes. This makes Tuskar UI significantly thicker than
> Dashboard is, and the natural parity between CLI and UI vanishes. By having
> this logic in UI, we're effectively preventing its use from CLI. (If i were
> bold i'd also think about integrating Tuskar with other software which would
> be prevented too if we keep the business logic in UI, but i'm not absolutely
> positive about use cases here).

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

> 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.

> Here are some options i see:
> 1) Make a thicker python-tuskarclient and put the business logic there. Make
> it consume other python-*clients. (This is an unusual approach though, i'm
> not aware of any python-*client that would consume and integrate other
> python-*clients.)

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

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

> 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.

> 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 :).

> 4) Keep python-tuskarclient thin, but build a separate CLI app that would
> provide same integration features as Tuskar UI does. (This would lead to
> code duplication. Depends on the actual amount of logic to duplicate if this
> is bearable or not.)


> Which of the options you see as best? Did i miss some better option? Am i
> just being crazy and trying to solve a non-issue? Please tell me :)

Not at all, definitely some very good points raised.

-- James Slagle

More information about the OpenStack-dev mailing list