A few clarifications added, next time i'll need to triple-read after
myself :)
On 11.12.2013 13:33, 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.
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).
Sorry, this should have said "not build Tuskar *UI* 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.)
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
"expose python bindings for Tuskar UI" is double-meaning - to be more
precise: "expose python bindings for use within Tuskar UI".
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
_______________________________________________
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
