Open Stack

On 12/11/2013 01:33 PM, Jiří Stránský wrote:
> Hi all,
>

Hi Jirka,

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

I would prefer this solution in cases where it can't be part of 
tuskar-api (option 2). It makes sense to me define an API which 
represent set of methods/actions from Tuskar POV (even if these methods 
just wrap API calls to other openstack APIs).

> 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.)
>
> 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? :) )
>
> 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 :)
>
> Please don't consider the time aspect of this, focus rather on what's
> the right approach, where we want to get eventually. (We might want to
> keep a thick Tuskar UI for Icehouse not to set the hell loose, there
> will be enough refactoring already.)
>
>
> Thanks
>
> Jirka
>

Jan