On 12/11/2013 04:35 PM, James Slagle wrote:
On Wed, Dec 11, 2013 at 7:33 AM, Jiří Stránský <ji...@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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
