Open Stack

----- Original Message -----
> From: "Zane Bitter" <zbitter at redhat.com>
> To: "OpenStack Development Mailing List" <openstack-dev at lists.openstack.org>
> Sent: Monday, 17 August, 2015 5:25:36 PM
> Subject: [openstack-dev] [TripleO] Encapsulating logic and state in the	client
> 
> It occurs to me that there has never been a detailed exposition of the
> purpose of the tripleo-common library here, and that this might be a
> good time to rectify that.
> 
> Basically, there are two things that it sucks to have in the client:
> 
> First, logic - that is, any code that is not related to the core client
> functionality of taking input from the user, making ReST API calls, and
> returning output to the user. This sucks because anyone needing to
> connect to a ReST API using a language other than Python has to
> reimplement the logic in their own language. It also creates potential
> versioning issues, because there's nothing to guarantee that the client
> code and anything it interacts with on the server are kept in sync.
> 
> Secondly, state. This sucks because the state is contained in a user's
> individual session, which not only causes all sorts of difficulties for
> anyone trying to implement a web UI but also means that you're at risk
> of losing some state if you e.g. accidentally Ctrl-C the CLI client.

Thinking about this further, the interesting question to me is how much
logic we aim to encapsulate behind an API. For example, one of the simpler
CLI commands we have in RDO-Manager (which is moving upstream[1]) is to 
run introspection on all of the Ironic nodes. This involves a series of 
commands that need to be run in order and it can take upwards of 20 
minutes depending how many nodes you have. However, this does just 
communicate with Ironic (and ironic inspector) so is it worth hiding 
behind an API? I am inclined to say that it is so we can make the end 
result as easy to consume as possible but I think it might be difficult
to draw the line in some cases.

The question then rises about what this API would look like? Generally 
speaking I feel like it looks like a workflow API, it shouldn't offer 
many (or any?) unique features, rather it manages the process of 
performing a series of operations across multiple APIs. There have been
attempts at doing this within OpenStack before in a more general case, 
I wonder what we can learn from those.

 
> Unfortunately, as undesirable as these are, they're sometimes necessary
> in the world we currently live in. The only long-term solution to this
> is to put all of the logic and state behind a ReST API where it can be
> accessed from any language, and where any state can be stored
> appropriately, possibly in a database. In principle that could be
> accomplished either by creating a tripleo-specific ReST API, or by
> finding native OpenStack undercloud APIs to do everything we need. My
> guess is that we'll find a use for the former before everything is ready
> for the latter, but that's a discussion for another day. We're not there
> yet, but there are things we can do to keep our options open to make
> that transition in the future, and this is where tripleo-common comes in.
> 
> I submit that anything that adds logic or state to the client should be
> implemented in the tripleo-common library instead of the client plugin.
> This offers a couple of advantages:
> 
> - It provides a defined boundary between code that is CLI-specific and
> code that is shared between the CLI and GUI, which could become the
> model for a future ReST API once it has stabilised and we're ready to
> take that step.
> - It allows for an orderly transition when that happens - we can have a
> deprecation period during which the tripleo-common library is imported
> into both the client and the (future, hypothetical) ReST API.
> 
> cheers,
> Zane.
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

[1]: https://review.openstack.org/#/c/215186/3/gerrit/projects.yaml,cm