<div dir="ltr">On Wed, Nov 29, 2017 at 9:51 PM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 19/11/17 03:08, Rabi Mishra wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
Hi All,<br>
<br>
As part of community goal[1] for Queens, we've completed the repo split and created the new project[2].<br>
<br>
The next objective to is to use the new plugin in our jobs. As we've merged some changes after the split, I've synced them and fixed some minor issues before using it in the gate jobs.<br>
<br>
These are very small changes and I would suggest we review/land them on priority (we don't have to keep syncing them again and again for broken jobs). We should probably *not approve* any changes to integration tests in heat before these go in.<br>
<br>
- Changes in heat-tempest-plugin (sync  missing patches and fixes)<br>
<a href="https://review.openstack.org/#/q/project:openstack/heat-tempest-plugin+topic:sync_from_heat" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/project:openstack/heat-temp<wbr>est-plugin+topic:sync_from_<wbr>heat</a><br>
<br>
- Use heat-tempest-plugin for integration jobs<br>
<a href="https://review.openstack.org/#/c/508112/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/508112/</a><br>
<br>
- Use heat-tempest-plugin for grenade job<br>
<a href="https://review.openstack.org/#/c/521246/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/521246/</a><br>
<br>
- Add heat integration jobs to heat-tempest-plugin check/gate queue<br>
<a href="https://review.openstack.org/#/c/521340/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/521340/</a><br>
   I guess this would result in some issues, where we can't add any changes to heat that breaks the existing tests, as the changes for both projects would have a circular dependency (not sure how it works atm with other plugins!).<br>
<br>
- Remove plugin an integration tests from heat (This has -1 atm as releasenote job is broken, waiting for infra to fix it)<br>
</span><a href="https://review.openstack.org/#/c/521263/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/521263/</a> <<a href="https://review.openstack.org/#/c/521263/" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/c/521263/</a>><span class="gmail-"><br>
<br>
I've also created an etherpad[3] to track these.<br>
<br>
Also, the plugin project is expected to be branchless (we may not backport these job changes to stable branches soon though), we've to find  a  way to run additional tests for any new feature only on > <release/branch>. AFAIK, other projects check api microversions supported and without microversions in heat, may be we've find an alternate way.<br>
</span></blockquote>
<br>
So from discussion on IRC today I learned that the plan agreed at the PTG was *not* to move all of heat_integrationtests to a separate repo, but just those tests that test the API and are likely to be used in the trademark program for verifying clouds.<br>
<br></blockquote><div><br></div><div>Well, the etherpad[1] for the session clearly mentions "<span class="gmail-author-a-z76zz87zz84zz83zrz82zqrlz122zxiz87zhmz76z">Create the new repo and import API and *scenario* tests" and *not* "that tests the API and likely to be used in trademark programs".  What you mentioned above is probably the conclusion from all the discussion we had on IRC yesterday.<br></span></div><div><span class="gmail-author-a-z76zz87zz84zz83zrz82zqrlz122zxiz87zhmz76z"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In my view that effectively means just the Gabbi tests.<br> 
<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
However, what is actually happening is that *all* of the integration/scenario tests are moving to the separate branchless repo. This looks to me like it will be a disaster for developer and reviewer productivity, and project quality[1]. (Other folks seem inclined to agree.)<br></blockquote><div><br></div><div>Just to make it clear, there had been several discussions on 'what to move'/'branchless or not' in meetings[2] and IRC discussions[3] and the change of plan to move functional tests was based on the following.</div><div><br></div><div>- All our tests are API driven. There is probably not much difference between functional and scenario (i.e. if we only move scenario tests, we would have the same kind of issues as we would with functional tests).</div><div><br></div><div>- All our tests run with tempest as test runner and use the same tempest configuration. Unless we run remaining in-tree tests without tempest, we would end-up with the same set problems which the goal wanted to address ( issues with in-tree tempest plugins).<br></div><div><br></div><div>- Current coverage of gabbi tests is very poor and we've never been serious to land the patches to complete the API coverage. One of the patches have been languishing in review queue since a year[4].</div><div><br></div><div>- As heat is the orchestration service, I would think testing heat from user/operator point of view is not only testing API and interoperability, but how it works with other services deployed and many of our functional tests[5] do that.  <br></div><div><br></div><div>As per my understanding, the issue of having tests in a separate repo and it's impact on developer productivity was discussed by the all concerned before accepting this as a community goal. Our problem is probably not different from some other projects[6].</div><div><br></div><div>It's little unfortunate that we've started discussing about these issues after most of stuff has been done. Having said that, it's never late to do the right thing that saves us from a disaster, if that's what it means:)</div><div><br></div><div>Given the option, I would prefer:</div><div><br></div><div>- We keep all tests in-tree and run them with tempest for the time being, which means we would not complete the goal. <br></div><div><br></div><div>- Complete the coverage for API tests, probably identify functional/scenario tests that are expected to be stable across branches and then move them out along with the API tests.</div><div><br></div><div>- Change the remaining in-tree tests to run without tempest at the gate, unless there is a solution to your question below. <br></div><div><br></div><div>[1] <a href="https://etherpad.openstack.org/p/heat-queens-ptg-tempest-plugin">https://etherpad.openstack.org/p/heat-queens-ptg-tempest-plugin</a><br></div><div>[2] <a href="http://eavesdrop.openstack.org/meetings/heat/2017/heat.2017-08-16-15.00.log.txt">http://eavesdrop.openstack.org/meetings/heat/2017/heat.2017-08-16-15.00.log.txt</a></div><div>[3] <a href="http://eavesdrop.openstack.org/irclogs/%23heat/%23heat.2017-09-29.log.html">http://eavesdrop.openstack.org/irclogs/%23heat/%23heat.2017-09-29.log.html</a></div>[4] <a href="https://review.openstack.org/#/c/421914/">https://review.openstack.org/#/c/421914/</a><br>[5] <a href="https://github.com/openstack/heat/blob/master/heat_integrationtests/functional/test_lbaasv2.py">https://github.com/openstack/heat/blob/master/heat_integrationtests/functional/test_lbaasv2.py</a></div><div class="gmail_quote">[6] <a href="https://github.com/openstack/neutron-tempest-plugin/blob/master/neutron_tempest_plugin/scenario/test_floatingip.py#L118">https://github.com/openstack/neutron-tempest-plugin/blob/master/neutron_tempest_plugin/scenario/test_floatingip.py#L118</a></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The QA team assures us that the project-wide goal does not preclude keeping tests that are designed for Heat CI purposes (rather than cloud verification purposes) in-tree - even continuing to use tempest as a testrunner. However, it's not at all clear how to reconcile that with the goal description listing the evils of having an in-tree tempest plugin.[2] This appears to be the reason for the change in plan.<br>
<br>
Does anybody remember what the mechanism for dealing with this that was agreed at the PTG was?<br>
<br>
Basically we need a way to:<br>
<br>
* Run a bunch of integration tests in Heat CI jobs<br>
* against a full OpenStack cloud<br>
* preferably using tempest as a testrunner, but this is optional<br>
* without any danger of e.g. breaking tempest test discovery just because Heat was installed on the same machine as tempest<br>
<br>
How do we do it?<br>
<br>
thanks,<br>
Zane.<br>
<br>
[1] <a href="http://eavesdrop.openstack.org/irclogs/%23heat/%23heat.2017-11-29.log.html#t2017-11-29T15:17:00" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org<wbr>/irclogs/%23heat/%23heat.2017-<wbr>11-29.log.html#t2017-11-29T15:<wbr>17:00</a><br>
[2] <a href="https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html#split-tempest-plugins-into-separate-repos-projects" rel="noreferrer" target="_blank">https://governance.openstack.o<wbr>rg/tc/goals/queens/split-tempe<wbr>st-plugins.html#split-tempest-<wbr>plugins-into-separate-repos-<wbr>projects</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
-- <br>
Regards,<br>
Rabi Mishra<br>
<br>
[1] <a href="https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html" rel="noreferrer" target="_blank">https://governance.openstack.o<wbr>rg/tc/goals/queens/split-tempe<wbr>st-plugins.html</a><br>
[2] <a href="https://git.openstack.org/cgit/openstack/heat-tempest-plugin" rel="noreferrer" target="_blank">https://git.openstack.org/cgit<wbr>/openstack/heat-tempest-plugin</a><br>
[3] <a href="https://etherpad.openstack.org/p/heat-tempest-plugin" rel="noreferrer" target="_blank">https://etherpad.openstack.org<wbr>/p/heat-tempest-plugin</a><br>
<br>
<br></span>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</blockquote>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Regards,</div>Rabi Mishra<div><br></div></div></div></div></div>
</div></div>