Open Stack

On Tue, Sep 12, 2017 at 9:58 PM, Jiri Tomasek <jtomasek at redhat.com> wrote:

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

Nice summary here. I think we do need to be more careful in how we add
features to python-tripleoclient so that we guard against breaking some of
the UI use cases. We have guarded some features on this front in the past
during the review process. When TripleO validations was added for instance
we were extra careful in how we execute Ansible (via Mistral) so that both
the UI and CLI could run it.


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

The python-client may be "lightweight" but the downstream packages that
typically install this are extremely heavy. This is largely due to the
instack-undercloud requirements that could arguably be split out into a
separate subpackage. Just a minor nit, that we might consider making the
package lighter for RPMs as well.


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

We don't have a lot (if any?) UI testing in our upstream CI architecture do
we? One potential action item that might help us cover the common use cases
across the CLI and GUI might be to run some of the python-tripleoclients on
a separate CI node instead of always using the undercloud. If for example
the plan was created on one node, but the overcloud deploy was driven from
a separate node it would ensure there are no localhost files being used
that aren't wired into the plan. There would be some work to get to this
point but I very much like the idea of python-tripleoclient behaving more
like a standard openstack client library in that it would interact with the
API's to do work.

Dan


> [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/8ea5fe5a/attachment.html>