I'm going to reply to Dean's and James' posts in one shot because it
imho makes most sense.
On 11.12.2013 17:00, Dean Troyer wrote:
On Wed, Dec 11, 2013 at 9:35 AM, James Slagle <james.sla...@gmail.com>wrote:
On Wed, Dec 11, 2013 at 7:33 AM, Jiří Stránský <ji...@redhat.com> wrote:
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?
Currently, tuskarclient is a library (Python bindings around tuskar-api)
and CLI on top of that library (though the CLI is not as complete as the
bindings).
I would expect tuskarclient above to be the Python API bindings without the
business logic.
Yes.
I don't think we want the business logic in the UI.
+1
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.
+1
At a minimum you need to be sure that all of the atomic operations in your
business logic are exposed via _some_ API. ie, to script something the
script may be where the business logic exists.
Building on that is moving that logic into a library that calls multiple
Python client APIs. This may or may not be part of tuskarclient.
The next step up is to put your business logic into what we used to call
middleware, the layer between client and backend. This is server-side and
IMHO where it belongs. This is really the ONLY way you can ensure that
various clients get the same experience.
python-openstackclient consumes other clients :). Ok, that's probably
not a great example :).
:) No, not really. But it is also developing some 'value-added' functions
that are cross-project APIs and has a similar problem. So far that is just
smoke and mirrors hiding the duck tape behind the scenes but it is not
unlike some of the things that Horizon does for user convenience.
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.
Yeah making tuskarclient consume other clients seems most appealing to
me as well. Solution 3 is very similar.
If you do this keep the low-level API bindings separate from the
higher-level logical API.
Agreed, this would be essential part of such solution. We'd need to have
separate namespaces for the low-level Python API (thin wrapper over
Tuskar REST API) vs. the high-level Python API (business logic on top of
the internal low-level Python API and 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.)
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.
Consider that pushig out to the client requires that the client be in sync
with what is deployed. You'll have to make sure your client logic can
handle the multiple versions of server APIs that it will encounter.
Putting that server-side lets you stay in sync with the other OpenStack
APIs you need to use.
Hmm this is quite a good argument for the server-side approach... But i
wonder if it's worth the complexity of proxying some (possibly a lot of)
API calls. If we don't need to keep any additional data about entities
(by entities i mean Heat stacks, Ironic nodes, ...), then i think having
a REST API just to ensure we can stay in sync with other services in the
release is a bit overkill. I don't think maintaining compatibility of
the client layer will be easy, but maintaining "the proxy" wouldn't be
easy either imho.
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 :).
1 and 3 are indeed very similar. The only difference is that in 3 the
high-level Python API and CLI would be a separate project (packaged
separately).
This is essentially what I suggested above. It need not be a separate repo
or installable package, but the internal API should have its own
namespace/modules/whatever.
Yeah i think separate namespace should be sufficient, to keep things simple.
Thanks! :)
Jirka
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
