Open Stack

Hello,

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.
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.

Best regards,
Anastasia Kuznetsova

On Fri, Mar 27, 2015 at 6:18 AM, Angus Salkeld <asalkeld at mirantis.com>
wrote:

> On Fri, Mar 27, 2015 at 6:26 AM, Zane Bitter <zbitter at 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?
>>
>
> I think the overall goal is to make it easier for an operator to run tests
> against their cloud to make sure
> everything is working. We should really have a common approach to this so
> they don't have to do something
> different for each project. Any opinions from the QA team?
>
> Maybe have it as it's own package, then you can install it and run
> something like:
> os-functional-tests-run <package-name> <auth args here>
>
> -A
>
>
>
>>
>> cheers,
>> Zane.
>>
>>  What do you think about it? Please share your comments.
>>>
>>> Best regards,
>>>
>>> Pavlo Shchelokovskyy
>>> Software Engineer
>>> Mirantis Inc
>>> www.mirantis.com <http://www.mirantis.com>
>>>
>>>
>>> ____________________________________________________________
>>> ______________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
>>> unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150327/b2b669af/attachment.html>