<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">I thought that OpenStack just support one release backwards, if we have to support three versions, this is not useful.</div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">There are already ways to enable/disable modules in tempest to adapt to each deployment needs. Just wanted to avoid more configuration options.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 16 April 2014 21:14, David Kranz <span dir="ltr"><<a href="mailto:dkranz@redhat.com" target="_blank">dkranz@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="">
<div>On 04/16/2014 11:48 AM, Jaume Devesa
wrote:<br>
</div>
</div><div class=""><blockquote type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:tahoma,sans-serif">Hi
Sean,</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">
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?</div>
</div>
</blockquote></div>
If we go down this route, and I think we should, we probably need to
accept that it will be hard for users to manually configure
tempest.conf. Tempest configuration would have to be done by
whatever installation technology was used, as devstack does, or by
auto-discovery. That implies that the presence of new features
should be discoverable through the api which is a good idea anyway.
Of course some one could configure it manually but IMO that is not
desirable even with where we are now.<div class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">Maybe
I am simplifying too much, but wouldn't be enough with a pair
of functions decorators like</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">@new</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">@deprecated</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">Then,
in tempest.conf it could be a flag to say which OpenStack
installation are you testing:</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">installation
= [icehouse|juno]</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">
<br>
</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">if
you choose Juno, tests with @new decorator will be executed
and tests with @deprecated will be skipped.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">
If you choose Icehouse, tests with @new decorator will be
skipped, and tests with @deprecated will be executed</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">
I am missing some obvious case that make this approach a
nonsense?</div>
</div>
</blockquote></div>
There are two problems with this. First, some folks are chasing
master for their deployments and some do not deploy all the features
that are set up by devstack. In both cases, it is not possible to
identify what can be tested with a simple name that corresponds to a
stable release. Second, what happens when we move on to K? The
meaning of "new" would have to change while retaining its old
meaning as well which won't work. I think Sean spelled out the
important scenarios.<span class="HOEnZb"><font color="#888888"><br>
<br>
-David</font></span><div><div class="h5"><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">Regards,</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">jaume</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 14 April 2014 15:21, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As we're
coming up on the stable/icehouse release the QA team is
looking<br>
pretty positive at no longer branching Tempest. The QA Spec
draft for<br>
this is here -<br>
<a href="http://docs-draft.openstack.org/77/86577/2/check/gate-qa-specs-docs/3f84796/doc/build/html/specs/branchless-tempest.html" target="_blank">http://docs-draft.openstack.org/77/86577/2/check/gate-qa-specs-docs/3f84796/doc/build/html/specs/branchless-tempest.html</a><br>
and hopefully address a lot of the questions we've seen so
far.<br>
<br>
Additional comments are welcome on the review -<br>
<a href="https://review.openstack.org/#/c/86577/" target="_blank">https://review.openstack.org/#/c/86577/</a><br>
or as responses on this ML thread.<br>
<span><font color="#888888"><br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
Samsung Research America<br>
<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>
/ <a href="mailto:sean.dague@samsung.com" target="_blank">sean.dague@samsung.com</a><br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</font></span><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>