----- Original Message ----- > From: "Zane Bitter" <zbit...@redhat.com> > To: "OpenStack Development Mailing List" <openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
