Open Stack

On 12/11/2013 04:35 PM, James Slagle wrote:
> 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.

Can you specify what kind of business logic?

Like we do validations in UI before we send it to API (both on server 
and client).
We occasionally do some joins. E.g. list of nodes is join of nova 
baremetal-list and nova list.

That is considered to be a business logic. Though if it is only for UI 
purposes, it should stay in UI.

Other than this, it's just API calls.

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

Sure, we have. It's just API calls. Though e.g. when you want massive 
instance delete, you will write a script for that in CLI. In UI you will 
filter it and use checkboxes.
So the equivalence is in API calls, not in the complex operations.

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

Guys, I am not sure about this. I thought python-xxxclient should follow 
Remote Proxy Pattern, being an object wrapper for the service API calls.

Even if you do this, it should call rather e.g. python-heatclient, 
rather than API directly. Though I haven't seen this one before in 
Openstack.


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

Shouldn't be general libs in the Oslo, rather than client?

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

I would really like to see client deciding which client to call 
use-case. Sounds a bit like an overengineering. :-)

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