<div dir="ltr">Hi everyone,<div><br></div><div>thanks to everyone who joined the QA track, hands-on session and discussions at the first PTG in Atlanta.</div><div>I think it was a very productive week, it was great to meet so many of you in person.</div><div>We also received a lot of feedback from the community [0].</div><div><br></div><div>The list of sessions is available at [1].</div><div>The list of priorities for the QA team during the Pike cycle is available at [2].</div><div><br></div><div>Below a summary of the areas we will be working on during Pike.</div><div>This is not an exhaustive list of all the topics we discussed at the PTG, see the session etherpads [1] for more.</div><div><br></div><div>Andrea</div><div><br></div><div>Tempest Stable Interfaces</div><div>====================</div><div><br></div><div>Credential providers are widely used in Tempest plugins [3], so they're top of the list in migrating to stable interfaces.</div><div>Tempest test base class is used by more than 45 different repos [3], so after as little as possible rework we will declare that class "as-is" a stable interface for plugins.</div><div>Other items planned to stable interfaces are: swift service client, waiters and potentially scenario helper methods.</div><div><br></div><div>Tempest Plugins</div><div>=============</div><div><br></div><div>We discussed about Tempest plugins and the proposed goal [4] to maintain them in branchless repos.</div><div>We clarified the implications of hosting the plugin in a branched repo / in the project repo [5]. </div><div><br></div><div>Documentation</div><div>============</div><div><br></div><div>One recurring items in the feedback was documentation. We will be working on generating documentation from all Tempest stable interfaces, and to add examples in there. We will enrich the documentation about writing plugins and contributing tests as well.</div><div><br></div><div>Scenario Tests</div><div>===========</div><div><br></div><div>Scenario tests have a long due refactor to be done, so we'll work on it during Pike.</div><div>We will be trying to make the process as smooth as possible for teams that depend on scenario test base classes today.</div><div><br></div><div>Policy Testing - Patrole</div><div>=================</div><div><br></div><div>During the Ocata cycle we introduced a new QA framework - Patrole [6] - for policy testing.</div><div>It's already discovered some inconsistencies in error codes, which is good news.</div><div>We have a lot of work planned on Patrole for the Pike cycle:</div><div>- setup CI gates</div><div>- make Patrole portable - similar to Tempest - so that it may be used to test existing deployments (public / private clouds)</div><div>- define Patrole interfaces for plugins</div><div><br></div><div>Schema Validation</div><div>==============</div><div><br></div><div>We plan to extend schema validation in Tempest to the six projects hosted there.</div><div>Plugins are encouraged to implement schema validation for the service they represent as well. No additional plugin interfaces are required for this.</div><div><br></div><div>Microversion Testing</div><div>================</div><div><br></div><div>We will stick to the current plan of updating micro version schemas in Tempest only when needed.</div><div>However we will monitor drift between implemented versions and tested ones, and we will make sure we fill the gap at least at the end of each cycle.</div><div><br></div><div>Grenade and Upgrade Testing</div><div>=======================</div><div><br></div><div>The current implementation of upgrade testing in Grenade provides a great service in our gates.</div><div>However it is not meant to fit more complex testing scenarios such as rolling upgrade, zero-downtime testing, validation using custom topologies and cross project upgrade dependencies. </div><div>We will investigate synergies with other projects to deploy topologies which are interesting for rolling upgrades, as well as for orchestrating the upgrade process itself, while keeping the existing upgrade test strategy available and stable via Grenade.</div><div><br></div><div>HA / Destructive Testing</div><div>==================</div><div><br></div><div>Interest on automated HA / Destructive testing has revived - see the email thread [7].</div><div>Starting with a third party CI service may be a good approach to asses the potential of this for upstream testing.</div><div><br></div><div>[0] <a href="https://etherpad.openstack.org/p/qa-ptg-pike-community-input">https://etherpad.openstack.org/p/qa-ptg-pike-community-input</a> </div><div>[1] <a href="https://etherpad.openstack.org/p/qa-ptg-pike">https://etherpad.openstack.org/p/qa-ptg-pike</a></div><div>[2] <a href="https://etherpad.openstack.org/p/pike-qa-priorities">https://etherpad.openstack.org/p/pike-qa-priorities</a> </div><div>[3] <a href="http://imgur.com/KDFeAf6">http://imgur.com/KDFeAf6</a> </div><div>[4] <a href="https://review.openstack.org/#/c/369749/">https://review.openstack.org/#/c/369749/</a> <br></div><div>[5] <a href="https://etherpad.openstack.org/p/qa-ptg-pike-tempest-plugins">https://etherpad.openstack.org/p/qa-ptg-pike-tempest-plugins</a> </div><div>[6] <a href="https://github.com/openstack/patrole">https://github.com/openstack/patrole</a> <br></div><div>[7] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-February/112848.html">http://lists.openstack.org/pipermail/openstack-dev/2017-February/112848.html</a> <br></div></div>