Open Stack

Hello all,

As we are in the planning phase for Queens cycle, I'd like to open the
discussion on the topic of CLI (tripleoclient) and GUI (tripleo-ui) feature
parity.

Two years ago, when TripleO UI was started, it was agreed that in order to
provide API for GUI and to achieve compatibility between GUI and CLI, the
TripleO business logic gets extracted from tripleoclient into
tripleo-common library and it will be provided through Mistral actions and
workflows so GUI and other potential clients can use it.

The problem:

Currently we are facing a recurring problem that when a new feature is
added to TripleO it often gets a correctly implemented business logic in
form of utility functions in tripleo-common but those are then used
directly by tripleoclient. At this point the feature is considered complete
as it is integrated in CLI and passes CI tests. The consequences of this
approach are:

- there is no API for the new feature, so the feature is only usable by CLI
- part of the business logic still lives in tripleoclient
- GUI can not support the feature and gets behind CLI capabilities
- GUI contributors need to identify the new feature, raise bugs [1],
feature then gets API support in tripleo-common
- API implementation is not tested in CI
- GUI and CLI diverges in how that feature is operated as business logic is
implemented twice, which has number of negative effects on TripleO
functionality (backwards compatibility, upgrades...)

The biggest point of divergence between GUI and CLI is that CLI tends to
generate a set of local files which are then put together when deploy
command is run whereas GUI operates on Deployment plan which is stored in
Swift and accessed through API provided by tripleo-common.

The described problem currently affects all of the features which CLI uses
to generate files which are used in deploy command (e.g. Roles management,
Container images preparation, Networks management etc.) There is no API for
those features and therefore GUI can't support them until Mistral actions
and workflows are implemented for it.

Proposed solution:

We should stop considering TripleO as a set of utility scripts used to
construct 'deploy' command, we should rather consider TripleO as a
deployment application which has its internal state (Deployment plan in
Swift) which is accessed and modified via API.
TripleO feature should be considered complete when API for it is created.
CLI should solely use TripleO business logic through Mistral actions and
workflows provided by tripleo-common - same as any other client has to.

Results of this change are:
- tripleoclient is extremely lightweight, containing no tripleo business
logic
- tripleo-common API is tested in CI as it is used by CLI
- tripleoclient and tripleo-ui are perfectly compatible, interoperable and
its features and capabilities match
- TripleO business logic lives solely in tripleo-common and is operated the
same way by any client
- no new backward compatibility problems caused by releasing features which
are not supported by API are not introduced
- new features related to Ansible or containers are available to all clients
- upgrades work the same way for deployments deployed via CLI and GUI
- deployment is replicable without need of keeping the the deploy command
and generated files around (exported deployment plan has all the
information)

Note that argument of convenience of being able to modify deployment files
locally is less and less relevant as we are incrementally moving from
forcing user to modify templates manually (all the jinja templating,
roles_data.yaml, network_data.yaml generation, container images
preparation, derive parameters workflows etc.). In Pike we have made
changes to simplify the way Deployment plan is stored and it is extremely
easy to import and export it in case when some manual changes are needed.

Proposed action items:
- Document what feature complete means in TripleO and how features should
be accessed by clients
- Identify steps to achieve feature parity between CLI and GUI
(tripleo-common) [2]
- Implement missing plan operations CLI commands to be able to deprecate
commands which generate local files which are used with deploy command

[1] https://bugs.launchpad.net/tripleo/+bug/1715377
[2] https://etherpad.openstack.org/p/tripleo-ui-queens-planning

Thanks
Jirka
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170913/dec91b2c/attachment.html>