----- Original Message ----- > 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. >
+1; as someone who's done work integrating OpenStack with external code bases (Ruby), I like this idea a lot. People have been extremely impressed with how easy it's been to integrate services like Nova or Ironic, and I think eventually enabling that sort of ease of integration with TripleO will be a good step in encouraging wider adoption of TripleO. Mainn > __________________________________________________________________________ > 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