On 11.12.2013 16:43, Tzu-Mainn Chen wrote:
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?
python-tuskarclient = Python bindings to tuskar-api + CLI, in one project
tuskar-ui doesn't have it's own bindings, it depends on
python-tuskarclient for bindings to tuskar-api (and other clients for
bindings to other APIs). UI makes use just of the Python bindings part
of clients and doesn't interact with the CLI part. This is the general
OpenStack way of doing things.
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?
Hmm i don't think there's been a thread yet, maybe this one will be :)
I think what i mostly heard was that we want a single source of truth
for things. Also i'd guess that going straight instead of proxying keeps
the overall architecture simpler. But maybe someone will have a better
point here :)
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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
