Open Stack

On 2017-09-13 12:45, Dan Prince wrote:
> 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.

We are in the early stages of introducing a tempest plugin for
tripleo-ui.  The project has been created, and we're working on
integrating it into upstream CI.

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

> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev