<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 19, 2017 at 6:51 PM Andrea Frittoli <<a href="mailto:andrea.frittoli@gmail.com">andrea.frittoli@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dear Bats,<div><br></div><div>thanks everyone for participating to the Queens PTG - in person and remotely - and for making it a successful and enjoyable event.</div><div><br></div><div>Here's a summary of what we discussed and achieved during the week.</div><div>This report is far from complete - please complement it with QA related stories I may have missed.</div><div><br></div><div>Unfortunately I ran out of bat stickers, I hope to have some more for the next time we meet :)</div><div><br></div><div>Pike Retrospective</div><div>-------------------------</div><div>We experimented this time with running a retrospective [0].</div><div>The input for the retrospective was almost exclusively from members of the QA team, which means that either the retrospective was poorly advertised by me, or that we did a nice job for the community during the QA cycle. I hope the latter :)</div><div><br></div><div>The outcome of the retrospective was mostly 'yay' for tasks completed, and 'next cycle' for things we did not have time to work on.</div><div>A few extra things that came up were:</div><div>- bug triage and fix: we may need a bug czar and more automation to stay on top of the bug queue</div><div>- elastic recheck categorisation: we may need an e-r czar to ensure we don't leave gate failures and races uncategorised and accumulating</div><div>- meetings are mostly attended in the APAC time zone and very seldom attended by non-qa folks. We will consider shortening / reducing them and complementing them with QA office hours</div><div><br></div><div>Monitoring the Gate</div><div>--------------------------</div><div>At the beginning of the Pike cycle we had a number of stability issues in the gate.</div><div>To prevent issues from accumulating over time we discussed a few ideas about monitoring the status of the gate and providing more feedback to reviewers to help catch patches that may introduce issues [1].</div><div>There are a few things that can be done relatively easily (or that we already have) in terms of data collection: job duration and failure rates, aggregated dstat data, resources created by tests.</div><div>We miss OpenStack Health contributors to create new views for this data. Links from gerrit and zuul dashboard into OpenStack Health would help making the data discoverable.</div><div><br></div><div>Tempest<br></div><div><div><div>------------</div></div><div>A large chunk of the patches required to mark test.py as a stable interface for plugins was merged during the summit.</div><div>It was good to have them merged during PTG so it was easier to fix resulting issues in Tempest plugins - at least Manila and Sahara needed a small patch.</div></div><div>There are two patch series left [2][3] which should have very little impact on plugins - we'll try to merge them as soon as possible to avoid disruptions later in the Queens cycle.</div><div><br></div><div>We worked with a few project teams on the goal to split Tempest plugins to a dedicated repo.</div><div>The step by step process [4] linked to the goal includes an example section - we hope to get more and more examples in there from team who already went through the process.</div><div><br></div><div>Devstack</div><div>------------</div><div>We discussed about devstack runtime. The time to setup an OpenStack cloud using devstack seems to have increased over time [5][6] - it would be good to investigate why and see if there is time we can save in the gate and on each developer laptop :) Between August and September the average runtime in the gate increased by about 200s.</div><div><br></div><div>Upgrade Testing<br></div><div>----------------------</div><div>Rolling upgrade testing via grenade is important for project that seek obtaining the support rolling upgrade tag [7]. </div><div>While the scope of Grenade is rather fixed, it should be possible to support ordering (or relative ordering) in project updates.</div><div><br></div><div>Policy Testing</div><div>------------------</div><div>We discussed what's next for the Queens cycle - support for multi-policy testing is the largest chunk of work planned for now.</div><div><br></div><div>stestr</div><div>-------</div><div>The migration in ostestr to use stestr internally happened shortly before the PTG [8] and we worked through the PTG to amend any deviation in behaviour that this may have caused.</div><div>Next in the todo list is to run stestr natively in Tempest, bypassing ostestr completely. </div><div>The plan is for this to lead the way for projects to gradually remove the dependency to ostestr completely.</div><div><br></div><div>HA Testing</div><div>---------------</div><div>We talked quite a bit about HA and non-functional testing in general. </div><div>Non-functional testing is not a good fit for gate testing, since it's not as reliable as functional / integration testing and it often produces results which needs to be interpreted by a human being.</div><div>It also has strong dependencies to the deployment tooling and architecture. Until now most of OpenStack non-functional testing has been done by vendors and operators using downstream tools.</div><div><br></div><div>SamP and guatamdivgi presented to the QA team a proposal for an Ansible based framework for HA testing [9]. Plugins will allow to seamlessly port different test scenario against different cloud architecture, thus rendering the framework of interest as a general testing tool for OpenStack. The same concept can be extended to non-functional testing in general.</div><div><br></div><div>It's not clear yet if any of this could run as part of OpenStack CI.  We hope to see a PoC after a couple of months in the Queens cycle. </div><div>The NFV ecosystem would be happy to see publicly available non-functional tests for OpenStack as well - if we had a common framework for such tests we'd have an opportunity to attract contributions into tests from them as well.</div><div><br></div><div>All things Zuul V3</div><div>-----------------------</div><div>Zuul v3 will provide a DB backend for test runs data, which we want to integrate as a new data source for OpenStack Health, so that we can then provide a full picture of all job runs in O-H.<br></div><div><br></div><div>Job names will change with zuul v3. While we found a simple solution to keep OpenStack Health data functional with Zuul v3 provided metadata, we will still loose 6 months of historical data in the process of migration, for which we don't have a solution yet.</div><div><br></div><div>In terms of Zuul v3 jobs, we started working on Zuul v3 native Tempest jobs [10]. this will be the basis for most jobs that run Tempest against devstack.</div><div>The patch is still WIP, but it already runs the full Tempest run, with only one test failure which I need to investigate.</div><div><br></div><div>QA Help Room</div><div>--------------------</div><div>The help room was helpful (heh, I couldn't resist) mostly on day 1.</div><div>It was good to have dedicated time allocated to answer questions, since it gave us space to open the laptop and work on code directly to answer specific questions.</div><div><br></div><div>There were no questions asked during day 2. We used the time to join other sessions and work on QA topics, but perhaps in Dublin we could consider having a single help room day.</div><div><br></div><div>Cross-Community</div><div>------------------------</div><div>NFV:</div><div>It was very interesting to discuss with the OPNFV community about CI and test processes and architecture.</div><div>The aim on both sides to re-use / share tools and best practices, share test results and avoid duplicate efforts where relevant.</div><div><br></div><div>K8S:</div><div>We discussed with dmellado the possibility of having a basic k8s client hosted in a Tempest plugin [11], that could be used by k8s related OpenStack project to write OpenStack / k8s scenario tests. The main advantages of a k8s client written in Tempest format and hosted by OpenStack would be a uniform interface with the OpenStack Tempest client and a stable testing API.</div><div><br></div><div>QA Themes for Queens</div><div>--------------------------------</div><div>We summarised the topics the QA team will focus on through the Queens cycle in out queens priority etherpad [11].</div><div>The main etherpad for QA at the PTG in Denver is available as well [12].</div><div><br></div><div>QA Team Pictures</div><div>------------------------</div><div>I'll forward the pictures as soon as I have a high-res copy available :)</div></div></blockquote><div><br></div><div><br></div><div>Team Pictures:</div><div><br></div><div><a href="https://photos.app.goo.gl/R6cuI7lAD6YKzwfF2">https://photos.app.goo.gl/R6cuI7lAD6YKzwfF2</a><br></div><div><br></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>Thanks for reading!</div><div><br></div><div>Andrea Frittoli (andreaf)</div><div><br></div><div>[0] <a href="https://etherpad.openstack.org/p/qa-pike-retrospective" target="_blank">https://etherpad.openstack.org/p/qa-pike-retrospective</a> </div><div>[1] <a href="https://etherpad.openstack.org/p/qa-pike-gate-performance" target="_blank">https://etherpad.openstack.org/p/qa-pike-gate-performance</a> </div><div>[2] <a href="https://review.openstack.org/#/q/topic:test_module_stable+(status:open+OR+status:merged" target="_blank">https://review.openstack.org/#/q/topic:test_module_stable+(status:open+OR+status:merged</a>) </div><div>[3] <a href="https://review.openstack.org/#/q/topic:bp/consistent-service-method-names+status:open+owner:%22Ghanshyam+Mann+%253Cghanshyammann%2540gmail.com%253E%22" target="_blank">https://review.openstack.org/#/q/topic:bp/consistent-service-method-names+status:open+owner:%22Ghanshyam+Mann+%253Cghanshyammann%2540gmail.com%253E%22</a> </div><div>[4] <a href="https://etherpad.openstack.org/p/tempest-separate-plugin" target="_blank">https://etherpad.openstack.org/p/tempest-separate-plugin</a></div><div>[5] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-September/122271.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2017-September/122271.html</a></div><div>[6] <a href="http://status.openstack.org/openstack-health/#/test/devstack?resolutionKey=day&duration=P6M" target="_blank">http://status.openstack.org/openstack-health/#/test/devstack?resolutionKey=day&duration=P6M</a> </div><div>[7] <a href="https://governance.openstack.org/tc/reference/tags/assert_supports-rolling-upgrade.html" target="_blank">https://governance.openstack.org/tc/reference/tags/assert_supports-rolling-upgrade.html</a></div><div>[8] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-September/122135.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2017-September/122135.html</a> </div><div>[9] <a href="https://etherpad.openstack.org/p/qa-queens-ptg-destructive-testing" target="_blank">https://etherpad.openstack.org/p/qa-queens-ptg-destructive-testing</a> </div><div>[10] <a href="https://review.openstack.org/#/c/504246/" target="_blank">https://review.openstack.org/#/c/504246/</a> </div><div>[11] <a href="https://etherpad.openstack.org/p/qa-queens-priorities" target="_blank">https://etherpad.openstack.org/p/qa-queens-priorities</a> </div><div>[12] <a href="https://etherpad.openstack.org/p/qa-queens-ptg" target="_blank">https://etherpad.openstack.org/p/qa-queens-ptg</a> </div></div></blockquote></div></div>