<div dir="ltr">Hello all,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>The problem:</div><div><br></div><div>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:</div><div><br></div><div>- there is no API for the new feature, so the feature is only usable by CLI</div><div>- part of the business logic still lives in tripleoclient</div><div>- GUI can not support the feature and gets behind CLI capabilities<br></div><div>- GUI contributors need to identify the new feature, raise bugs [1], feature then gets API support in tripleo-common</div><div>- API implementation is not tested in CI</div><div>- 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...)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Proposed solution:</div><div><br></div><div>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.</div><div>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.<br></div><div><br></div><div>Results of this change are:</div><div>- tripleoclient is extremely lightweight, containing no tripleo business logic</div><div>- tripleo-common API is tested in CI as it is used by CLI</div><div>- tripleoclient and tripleo-ui are perfectly compatible, interoperable and its features and capabilities match</div><div>- TripleO business logic lives solely in tripleo-common and is operated the same way by any client</div><div>- no new backward compatibility problems caused by releasing features which are not supported by API are not introduced</div><div>- new features related to Ansible or containers are available to all clients</div><div>- upgrades work the same way for deployments deployed via CLI and GUI</div><div>- deployment is replicable without need of keeping the the deploy command and generated files around (exported deployment plan has all the information)</div><div><br></div><div>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.</div><div><br></div><div>Proposed action items:</div><div>- Document what feature complete means in TripleO and how features should be accessed by clients</div><div>- Identify steps to achieve feature parity between CLI and GUI (tripleo-common) [2]</div><div>- Implement missing plan operations CLI commands to be able to deprecate commands which generate local files which are used with deploy command</div><div><br></div><div>[1] <a href="https://bugs.launchpad.net/tripleo/+bug/1715377">https://bugs.launchpad.net/tripleo/+bug/1715377</a></div><div>[2] <a href="https://etherpad.openstack.org/p/tripleo-ui-queens-planning">https://etherpad.openstack.org/p/tripleo-ui-queens-planning</a></div><div><br></div><div>Thanks</div><div>Jirka</div></div>