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