Open Stack

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.

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.