<div dir="ltr">On Thu, Apr 27, 2017 at 3:55 PM, Andrea Frittoli <span dir="ltr"><<a href="mailto:andrea.frittoli@gmail.com" target="_blank">andrea.frittoli@gmail.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"><div dir="ltr">Dear stackers,<div><br></div><div>starting in the Liberty cycle Tempest has defined a set of projects which are in scope for direct</div><div>testing in Tempest [0]. The current list includes keystone, nova, glance, swift, cinder and neutron.</div><div>All other projects can use the same Tempest testing infrastructure (or parts of it) by taking advantage<br></div><div>the Tempest plugin and stable interfaces.</div><div><br></div><div>Tempest currently hosts a set of API tests as well as a service client for the Heat project.</div><div>The Heat service client is used by the tests in Tempest, which run in Heat gate as part of the grenade</div><div>job, as well as in the Tempest gate (check pipeline) as part of the layer4 job.</div><div>According to code search [3] the Heat service client is also used by Murano and Daisycore.</div></div></blockquote><div><br>For the heat grenade job, I've proposed two patches.<br><br></div><div>1. To run heat tree gabbi api tests as part of grenade 'post-upgrade' phase<br><br><a href="https://review.openstack.org/#/c/460542/" target="_blank">https://review.openstack.org/#<wbr>/c/460542/</a><br></div><div><br></div><div>2. To remove tempest tests from the grenade job<br><br><a href="https://review.openstack.org/#/c/460810/" target="_blank">https://review.openstack.org/#<wbr>/c/460810/</a><br><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>I proposed a patch to Tempest to start the deprecation counter for Heat / orchestration related</div><div>configuration items in Tempest [4], and I would like to make sure that all tests and the service client</div><div>either find a new home outside of Tempest, or are removed, by the end the Pike cycle at the latest.</div><div><br></div><div>Heat has in-tree integration tests and Gabbi based API tests, but I don't know if those provide</div><div>enough coverage to replace the tests on Tempest side. </div><div><br></div></div></blockquote><div><br>Yes, the heat gabbi api tests do not yet have the same coverage as the 
tempest tree api tests (lacks tests using nova, neutron and swift resources),  but I think that should not stop us from
 *not* running the tempest tests in the grenade job. <br><br>I also don't know if the tempest tree heat tests are used by any other upstream/downstream jobs. We could surely add more tests to bridge the gap. <br><br>Also, It's possible to run the heat integration tests (we've enough coverage there) with tempest plugin after doing some initial setup, as we do in all our dsvm gate jobs.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>It would propose to move tests and client to a Tempest plugin owned / maintained by</div><div>the Heat team, so that the Heat team can have full flexibility in consolidating their integration</div><div>tests. For Murano and Daisycloud - and any other team that may want to use the Heat service</div><div>client in their tests, even if the client is removed from Tempest, it would still be available via</div><div>the Heat Tempest plugin. As long as the plugin implements the service client interface,</div><div>the Heat service client will register automatically in the service client manager and be available</div><div>for use as today.</div><div><br></div></div></blockquote><div><br></div><div>if I understand correctly, you're proposing moving the existing tempest tests and service clients to a separate repo managed by heat team. Though that would be collective decision, I'm not sure that's something I would like to do. To start with we may look at adding some of the missing pieces in heat tree itself.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Andrea Frittoli (andreaf)</div><div><br></div><div>[0] <a href="https://docs.openstack.org/developer/tempest/test_removal.html#tempest-scope" target="_blank">https://docs.openstack.org<wbr>/developer/tempest/test_remova<wbr>l.html#tempest-scope</a></div><div>[1] <a href="https://docs.openstack.org/developer/tempest/plugin.html" target="_blank">https://docs.openstack.org<wbr>/developer/tempest/plugin.html</a><wbr> </div><div>[2] <a href="https://docs.openstack.org/developer/tempest/library.html" target="_blank">https://docs.openstack.org<wbr>/developer/tempest/library.htm<wbr>l</a> </div><div>[3] <a href="http://codesearch.openstack.org/?q=self.orchestration_client&i=nope&files=&repos=" target="_blank">http://codesearch.openstac<wbr>k.org/?q=self.orchestration_<wbr>client&i=nope&files=&repos=</a> </div><div>[4] <a href="https://review.openstack.org/#/c/456843/" target="_blank">https://review.openstack.o<wbr>rg/#/c/456843/</a> </div></div>
<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>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail-m_7715246154116477092gmail_signature"><div dir="ltr"><div>Regards,</div>Rabi Mishra<div><br></div></div></div>
</div></div>