Open Stack

On 18/08/15 02:33, Clint Byrum wrote:
> 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?

I can provide a specific example of what's in tripleo-common today: the 
workflow which drives package updates on the overcloud nodes. It works 
by kicking off a Heat stack-update and using hooks/breakpoints to 
shepherd it through the correct workflow - so this incorporates both 
logic and state.

In terms of what additional stuff might be added in the future, I was 
intentionally being somewhat generic in the hope that people would 
recognise their own situation in this description rather than try to 
predict what changes people might want to make in the future. I can 
imagine something like additional verification of input parameters (i.e. 
verifying them in combination, in a way that is application-specific and 
therefore cannot be done by Heat) would be an example we might hit.

cheers,
Zane.