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.
> 
> 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.

+1, I've felt uneasy about the state of the CLI at the moment and I can
see real advantage in having a relatively think API that captures all of
this logic and workflow.

 
> 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.

The other really big win is that it opens up the possibility of UIs and
CLIs written in other languages. A completely client side UI for example :)

> 
> 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
>