Hi, On Thu, Mar 26, 2015 at 10:26 PM, Zane Bitter <zbit...@redhat.com> wrote:
> On 26/03/15 10:38, Pavlo Shchelokovskyy wrote: > >> Hi all, >> >> following IRC discussion here is a summary of what I propose can be done >> in this regard, in the order of increased decoupling: >> >> 1) make a separate requirements.txt for integration tests and modify the >> tox job to use it. The code of these tests is pretty much decoupled >> already, not using any modules from the main heat tree. The actual >> dependencies are mostly api clients and test framework. Making this >> happen should decrease the time needed to setup the tox env and thus >> speed up the test run somewhat. >> > > +1 > > 2) provide separate distutils' setup.py/setup.cfg >> <http://setup.py/setup.cfg> to ease packaging and installing this test >> suit to run it against an already deployed cloud (especially scenario >> tests seem to be valuable in this regard). >> > > +1 > > 3) move the integration tests to a separate repo and use it as git >> submodule in the main tree. The main reasons not to do it as far as I've >> collected are not being able to provide code change and test in the same >> (or dependent) commits, and lesser reviewers' attention to a separate >> repo. >> > > -0 > > 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? > 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. 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. Best regards, Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev