Open Stack

Thanks for writing this all out!

----- Original Message -----
> Disclaimer: I swear I'll stop posting this sort of thing soon, but I'm
> new to the project. I only mention it again because it's relevant in
> that I missed any of the discussion on why proxying from tuskar API to
> other APIs is looked down upon. Jiri and I had been talking yesterday
> and he mentioned it to me when I started to ask these same sorts of
> questions.
> 
> On 12/11/2013 07:33 AM, Jiří Stránský 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.
> 
> My biggest concern was that having each client call out to the
> individual APIs directly put a lot of knowledge into the clients that
> had to be replicated across clients. At the best case, that's simply
> knowing where to look for data. But I suspect it's bigger than that and
> there are workflows that will be implemented for tuskar needs. If the
> tuskar API can't call out to other APIs, that workflow implementation
> needs to be done at a higher layer, which means in each client.
> 
> Something I'm going to talk about later in this e-mail but I'll mention
> here so that the diagrams sit side-by-side is the potential for a facade
> layer that hides away the multiple APIs. Lemme see if I can do this in
> ASCII:
> 
> tuskar-ui -+               +-tuskar-api
>             |               |
>             +-client-facade-+-nova-api
>             |               |
> tuskar-cli-+               +-heat-api
> 
> The facade layer runs client-side and contains the business logic that
> calls across APIs and adds in the tuskar magic. That keeps the tuskar
> API from calling into other APIs* but keeps all of the API call logic
> abstracted away from the UX pieces.
> 
> * Again, I'm not 100% up to speed with the API discussion, so I'm going
> off the assumption that we want to avoid API to API calls. If that isn't
> as strict of a design principle as I'm understanding it to be, then the
> above picture probably looks kinda silly, so keep in mind the context
> I'm going from.
> 
> For completeness, my gut reaction was expecting to see something like:
> 
> tuskar-ui -+
>             |
>             +-tuskar-api-+-nova-api
>             |            |
> tuskar-cli-+            +-heat-api
> 
> Where a tuskar client talked to the tuskar API to do tuskar things.
> Whatever was needed to do anything tuskar-y was hidden away behind the
> tuskar API.
> 
> > 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.
>
> When you say python- clients, is there a distinction between the CLI and
> a bindings library that invokes the server-side APIs? In other words,
> the CLI is packaged as CLI+bindings and the UI as GUI+bindings?
> 
> > 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 see your point about preventing its use from the CLI, but more
> disconcerting IMO is that it just doesn't belong in the UI. That sort of
> logic, the "Heat things behind the scenes", sounds like the jurisdiction
> of the API (if I'm reading into what that entails correctly).
> 
> > 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?)
> 
> To reiterate my point above, I see the idea of getting the CLI on par,
> but I also see it as striving for a cleaner design as well.
> 
> > 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.)
> 
> -1 in favor of #3 below (spoiler: I'm -1 to that too, I suppose this is
> a -2)
> 
> > 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.)
> 
> A tentative +1. Tentative until I dig up the feedback on intra-API calls
> and see why it was negative, in which case I may buy into those
> arguments too.

I'd be +1 for this; I don't fully understand why intra-API calls are negative
either, was there a previous thread that outlined the deficiencies?

In fact, I'd advocate going a little bit farther than what we did in the demo
iteration.  Here's a specific case:

For the demo, it was decided that the UI would call the Baremetal API directly
for things like registering nodes and retrieving a node list.  That seemed to
make sense at the time.  Later, we realized that Tuskar had its own concept of
a node (used for node/rack associations).  So we had to make two separate queries
and outer join the two, which led to some convoluted logic in the UI, and left
me wondering - wouldn't a CLI need to use exactly the same logic?

It would make more sense to me to push that sort of thing into the API.


> > 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.
> 
> > 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.)
> 
> I don't know the level of logic duplication that would happen, but the
> design feels wrong from the start.
> 
> > 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 :)
> 
> I'm not saying you're not crazy. I'm saying you're not alone in being
> crazy if you are  :)
> 
> > 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
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>