[openstack-dev] [Openstack-operators] [all][qa][gabbi][rally][tempest] Extend "rally verfiy" to unify work with Gabbi, Tempest and all in-tree functional tests

Andrey Kurilin akurilin at mirantis.com
Thu Mar 19 21:50:26 UTC 2015


I have an alternative solution for `rally verify <project> start` command.
What do you think about similar management stuff for verifiers as we have
for deployments?

It requires several changes:
 - `rally verifiers` command: Implementation of new command, which will
manage(install, reinstall, remove, configure) verifiers(tempest,
project-specific functional tests, gabbi and etc), will allow users to have
several tempest verifiers with different configurations or branches and
easily switch between them.
 - `rally verify` command: The original verification command will check
selected verifier and contain only verifier-specific sub-commands.
 - db changes: we will need to store information about verifiers


On Thu, Mar 12, 2015 at 2:33 AM, Boris Pavlovic <boris at pavlovic.me> wrote:

> Alex,
>
>
>   * rally plugin should be a part of project (for example, located in
>> functional tests directory)
>
>
> There are 2 issues with such solution:
>
>   1) If rally didn't load plugin, command "rally verify <project>" won't
> exist
>   2) Putting some strange Rally plugin to source of other projects will be
> quite complicated task.
>       I believe we should have at least POC before even asking for such
> stuff.
>
>   * use {project url} instead of {project name} in rally verify command,
>> example:
>
>
> I agree here with Andrey, it is bad UX. Forcing people to write every time
> URLs is terrible.
> They will build own tools on top of such solution.
>
> What  about "rally verify nova start --url <....>" where --url is optional
> argument?
> If "--url" is not specified default url is used.
>
>
> Best regards,
> Boris Pavlovic
>
>
>
>
>
>
> On Wed, Mar 11, 2015 at 7:14 PM, Andrey Kurilin <akurilin at mirantis.com>
> wrote:
>
>> > $ rally verify https://github.com/openstack/nova start
>>
>> As one of end-users of Rally, I dislike such construction, because I
>> don't want to remember links to repos, they are too long for me:)
>>
>> On Wed, Mar 11, 2015 at 12:49 PM, Aleksandr Maretskiy <
>> amaretskiy at mirantis.com> wrote:
>>
>>> The idea is great, but IMHO we can move all project-specific code out of
>>> rally, so:
>>>
>>>   * rally plugin should be a part of project (for example, located in
>>> functional tests directory)
>>>   * use {project url} instead of {project name} in rally verify command,
>>> example:
>>>
>>>         $ rally verify https://github.com/openstack/nova start
>>>
>>>
>>> On Tue, Mar 10, 2015 at 6:01 PM, Timur Nurlygayanov <
>>> tnurlygayanov at mirantis.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I like this idea, we use Rally for OpenStack clouds verification at
>>>> scale and it is the real issue - how to run all functional tests from each
>>>> project with the one script. If Rally will do this, I will use Rally to run
>>>> these tests.
>>>>
>>>> Thank you!
>>>>
>>>> On Mon, Mar 9, 2015 at 6:04 PM, Chris Dent <chdent at redhat.com> wrote:
>>>>
>>>>> On Mon, 9 Mar 2015, Davanum Srinivas wrote:
>>>>>
>>>>>  2. Is there a "test" project with Gabbi based tests that you know of?
>>>>>>
>>>>>
>>>>> In addition to the ceilometer tests that Boris pointed out gnocchi
>>>>> is using it as well:
>>>>>
>>>>>    https://github.com/stackforge/gnocchi/tree/master/gnocchi/
>>>>> tests/gabbi
>>>>>
>>>>>  3. What changes if any are needed in Gabbi to make this happen?
>>>>>>
>>>>>
>>>>> I was unable to tell from the original what "this" is and how gabbi
>>>>> is involved but the above link ought to be able to show you how
>>>>> gabbi can be used. There's also the docs (which could do with some
>>>>> improvement, so suggestions or pull requests welcome):
>>>>>
>>>>>    http://gabbi.readthedocs.org/en/latest/
>>>>>
>>>>> --
>>>>> Chris Dent tw:@anticdent freenode:cdent
>>>>> https://tank.peermore.com/tanks/cdent
>>>>>
>>>>> ____________________________________________________________
>>>>> ______________
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Timur,
>>>> Senior QA Engineer
>>>> OpenStack Projects
>>>> Mirantis Inc
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>>
>>>
>>
>>
>> --
>> Best regards,
>> Andrey Kurilin.
>>
>> __________________________________________________________________________
>> 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
>
>


-- 
Best regards,
Andrey Kurilin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150319/4c63bb74/attachment.html>


More information about the OpenStack-dev mailing list