Open Stack

Hi Sean,

for what I understood, we will need a new feature flag for each new
feature, and a feature flag (default to false) for each deprecated one. My
concern is: since the goal is make tempest a confident tool to test any
installation and not and 'tempest.conf' will not be auto-generated from any
tool as devstack does, wouldn't be too hard to prepare a tempest.conf file
with so many feature flags to enable and disable?

Maybe I am simplifying too much, but wouldn't be enough with a pair of
functions decorators like

@new
@deprecated

Then, in tempest.conf it could be a flag to say which OpenStack
installation are you testing:

installation = [icehouse|juno]

if you choose Juno, tests with @new decorator will be executed and tests
with @deprecated will be skipped.
If you choose Icehouse, tests with @new decorator will be skipped, and
tests with @deprecated will be executed

I am missing some obvious case that make this approach a nonsense?

Regards,
jaume


On 14 April 2014 15:21, Sean Dague <sean at dague.net> wrote:

> As we're coming up on the stable/icehouse release the QA team is looking
> pretty positive at no longer branching Tempest. The QA Spec draft for
> this is here -
>
> http://docs-draft.openstack.org/77/86577/2/check/gate-qa-specs-docs/3f84796/doc/build/html/specs/branchless-tempest.html
> and hopefully address a lot of the questions we've seen so far.
>
> Additional comments are welcome on the review -
> https://review.openstack.org/#/c/86577/
> or as responses on this ML thread.
>
>         -Sean
>
> --
> Sean Dague
> Samsung Research America
> sean at dague.net / sean.dague at samsung.com
> http://dague.net
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20140416/6f2e7fc3/attachment.html>