Open Stack

Excerpts from Zane Bitter's message of 2015-08-17 09:25:36 -0700:
> 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.
> 

I agree with most everything you've said above. But as someone mostly
disconnected from TripleO for the last 6 months, I have no idea what
you're talking about, specifically. Can you provide a specific example?