[openstack-qa] [Openstack-qa-team] Script to prepare the stack for full tempest run.

Jaroslav Henner jhenner at redhat.com
Fri Jun 14 07:42:14 UTC 2013

On Pá 14. červen 2013, 09:09:59 CEST, Attila Fazekas wrote:
> Lot of people does not see the true value of tempest like installation
> and deployment independent testing.
> - These are the tests what all OpenStack user/admin/system integrator can share on.
> - Tempest contains most of the tests what can work regardless to any topology or infra...
> - Tempest can be isolated from the inspected deployment by multiple ways.
> This bug about isolation tempest cli tests and cli utilities:
> https://bugs.launchpad.net/tempest/+bug/1150296
> Tempest even does not have to be on any machine which is part of the deployment,
>   so it can be even on different machine when you issue a multi-node packstack install.
> This is the place where I prefer the isolation, instead of saving nodes.
> But, you can run multiple tempest process on single node against multiple different deployment.
> (tempest itself not a resource hunger process)
> - run packstack or devstack or whatever is not the first step in any testing and not the last.
> - packstack is not the only way to deploy RDO or RHOS.
> If I had choose where to implement a __generic__ solution for fully prepare tempest test,
> it will not be in packstack repo or the tempest repo.
> What I would really recommend is extending the tempest documentation
> with a generic manual setup documentation
> which contains copy paste-able code snippets and descriptions.
> Preparing tempest automatically is not an issue.
> What I would recommend (I created bugs in the bz) for packstack,
> is changing the default settings to be more tempest friendly.

It is *the* issue. We need to have automated way of having those two 
projects working together. I don't think any automated script would be 
parsing the docs and doing copy-paste to the terminal.

> I have additional packstack enhancement recommendation,
> about what logic could be moved to the packstack.

I think mmagr accepts patches.

> ----- Original Message -----
> From: "Jaroslav Henner" <jhenner at redhat.com>
> To: "All Things QA." <openstack-qa at lists.openstack.org>
> Cc: "Sean Dague" <sean at dague.net>
> Sent: Thursday, June 13, 2013 5:40:17 PM
> Subject: Re: [openstack-qa] [Openstack-qa-team] Script to prepare the stack for full tempest run.
> On Čt 13. červen 2013, 17:08:52 CEST, Sean Dague wrote:
>> On 06/13/2013 10:59 AM, James Michel wrote:
>>> On 13/06/13 14:50, Jaroslav Henner wrote:
>>>> Hi,
>>>> We wish to create some tool for automated preparation of stack for full
>>>> tempest run. We need it to be able to work with deployment that has
>>>> been
>>>> prepared by Packstack [1].
>>>> Packstack can give as an output some "answer file", which is
>>>> actually an
>>>> ini file. We can parse that file, take some other values as input, for
>>>> example images locations, ... and create a tempest.conf accordingly.
>>> Actually we were looking at some smart way of configuring tempest.conf
>>> after having deployed openstack. Is this more-or-less what you had in
>>> mind?
> Yes but it is ... bit less than I had in mind. We need at least to
> upload the images for testing (cirros), increase quotas, add testing
> users. That's not what I would expect from the deploying tool to do.
> Maybe if I called it with some --test parameter I would.
>>>> The questions now are:
>>>>    * Should this be a part of Tempest?
>>>>    * Should this be a separate project?
>>>>    * Should this be a part of the Packstack?
>>>>    * What about other deploying tools - should that tool have several
>>>> frond-ends?
>>>>    * Does anybody have something already?
>>>> Any comments?
>>>> [1] https://wiki.openstack.org/wiki/Packstack
>>>> PS: As Attila Fazekas pointed, most things we can find dynamically from
>>>> the keystone/nova. True, but I don't quite like the idea to ssh to nova
>>>> host to get nova SQL password and tricks like that.
>>>> Jaroslav Henner
>> So I really think that these tempest configuration generators should
>> be back in the install tools themselves. We do this in devstack today,
>> and the installer should just configure tempest.conf as it's output.
>> It's not clear that an intermediary tool is really useful, because it
>> means that when your installer enables a new feature, you have to fix
>> the installer -> question file, then fix question engine -> tempest.
>>      -Sean
> _______________________________________________
> openstack-qa mailing list
> openstack-qa at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa

More information about the openstack-qa mailing list