On 2017-09-13 12:45, Dan Prince wrote: > On Tue, Sep 12, 2017 at 9:58 PM, Jiri Tomasek <jtoma...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ 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
