<div dir="ltr">Hello,<div><br></div><div>As a QA engineer, I like the idea to make integration tests more independent and have an ability to package them and run against any deployed cloud, it will be very useful. </div><div>But I assume, that creating a separate repository is not needed and it is enough to just collect all functional/integration tests in separate folder like now.</div><div><br></div><div>Best regards,</div><div>Anastasia Kuznetsova</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 27, 2015 at 6:18 AM, Angus Salkeld <span dir="ltr"><<a href="mailto:asalkeld@mirantis.com" target="_blank">asalkeld@mirantis.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"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Fri, Mar 27, 2015 at 6:26 AM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 26/03/15 10:38, Pavlo Shchelokovskyy wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
following IRC discussion here is a summary of what I propose can be done<br>
in this regard, in the order of increased decoupling:<br>
<br>
1) make a separate requirements.txt for integration tests and modify the<br>
tox job to use it. The code of these tests is pretty much decoupled<br>
already, not using any modules from the main heat tree. The actual<br>
dependencies are mostly api clients and test framework. Making this<br>
happen should decrease the time needed to setup the tox env and thus<br>
speed up the test run somewhat.<br>
</blockquote>
<br></span>
+1<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
2) provide separate distutils' <a href="http://setup.py/setup.cfg" target="_blank">setup.py/setup.cfg</a><br></span>
<<a href="http://setup.py/setup.cfg" target="_blank">http://setup.py/setup.cfg</a>> to ease packaging and installing this test<span><br>
suit to run it against an already deployed cloud (especially scenario<br>
tests seem to be valuable in this regard).<br>
</span></blockquote>
<br>
+1<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) move the integration tests to a separate repo and use it as git<br>
submodule in the main tree. The main reasons not to do it as far as I've<br>
collected are not being able to provide code change and test in the same<br>
(or dependent) commits, and lesser reviewers' attention to a separate repo.<br>
</blockquote>
<br></span>
-0<br>
<br>
I'm not sure what the advantage is here, and there are a bunch of downsides (basically, I agree with Ryan). Unfortunately I missed the IRC discussion, can you elaborate on how decoupling to this degree might help us?<br></blockquote><div><br></div></span><div>I think the overall goal is to make it easier for an operator to run tests against their cloud to make sure</div><div>everything is working. We should really have a common approach to this so they don't have to do something</div><div>different for each project. Any opinions from the QA team?</div><div><br></div><div>Maybe have it as it's own package, then you can install it and run something like:</div><div>os-functional-tests-run <package-name> <auth args here></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-A</div></font></span><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
cheers,<br>
Zane.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
What do you think about it? Please share your comments.<br>
<br>
Best regards,<br>
<br>
Pavlo Shchelokovskyy<br>
Software Engineer<br>
Mirantis Inc<br>
</span><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a> <<a href="http://www.mirantis.com" target="_blank">http://www.mirantis.com</a>><span><br>
<br>
<br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</span></blockquote><div><div>
<br>
<br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></span></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>