<div dir="ltr"><div class="gmail_extra"><div><div><div>Hi,</div></div></div>
<br><div class="gmail_quote">On Thu, Mar 26, 2015 at 10:26 PM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 26/03/15 10:38, Pavlo Shchelokovskyy wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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><div>Presumably this could enable a more streamlined packaging and publishing of the test suit (e.g. to PyPI). But I agree, right now it is not really needed given the downsides, I just brought it up as an extreme separation case to collect more opinions.</div><div><br></div><div>Given the feedback we have in the thread, I will proceed with the first point as this should have immediate benefit for the duration of the test job and already give help to those who want to package the test suit separately. Distutils stuff can be added later.</div><div><br></div><div>Best regards, </div><div><br></div>Pavlo Shchelokovskyy<div>Software Engineer</div><div>Mirantis Inc</div><div><a href="http://www.mirantis.com/" target="_blank">www.mirantis.com</a> </div></div><br></div></div>