<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 12, 2017 at 9:58 PM, Jiri Tomasek <span dir="ltr"><<a href="mailto:jtomasek@redhat.com" target="_blank">jtomasek@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>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.</div><div><br></div><div>Dan</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>[1] <a href="https://bugs.launchpad.net/tripleo/+bug/1715377" target="_blank">https://bugs.launchpad.<wbr>net/tripleo/+bug/1715377</a></div><div>[2] <a href="https://etherpad.openstack.org/p/tripleo-ui-queens-planning" target="_blank">https://etherpad.<wbr>openstack.org/p/tripleo-ui-<wbr>queens-planning</a></div><div><br></div><div>Thanks</div><div>Jirka</div></div>
</blockquote></div><br></div></div>