<div dir="ltr">Matt,<div><br></div><div>Thanks for the input; after reading Jay's story I was kind of sure that there was a precise reason for not using extension auto-discovery.</div><div>I will then start adding configuration variarables to tests exercising Neutron extensions; and ensure in reviews that these variables are added.</div>
<div>I think we should follow Jay's advice on naming. Something like the follow should work</div><div><br></div><div>neutron_<ext_alias> = {on|off} </div><div><br></div><div>Thanks,</div><div>Salvatore</div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On 17 October 2013 17:34, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 10/17/2013 10:46 AM, Matthew Treinish wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Oct 17, 2013 at 10:10:15AM -0400, Jay Pipes wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/17/2013 08:46 AM, Salvatore Orlando wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
in the discussion for patch <a href="https://review.openstack.org/#/c/50880/" target="_blank">https://review.openstack.org/#<u></u>/c/50880/</a> Sean<br>
asked a very reasonable question:<br>
<br>
"so are all these [Neutron] extensions always loaded on all<br>
environments? If not, how are we detecting which are?"<br>
<br>
So far we've been relying on devstack-gate setup, I think. If the<br>
extension is enabled by devstack-gate, then you can add the test. This<br>
would make sense if tempest is used exclusively by the upstream gate<br>
jobs, which however appears not to be the case. It should therefore be<br>
possible to select which tests should be run according to currently<br>
enabled Neutron extensions, which depend on core and service plugins<br>
<br>
One way to solve this issue would be to use tempest configuration<br>
variables; while this is the simplest approach, there are already 25<br>
extensions in Neutron, not counting plugin-specific extensions. This<br>
number can only grow in future releases, so I have a few concerns about<br>
maintainability of this approach because of the high number of<br>
configuration variables.<br>
<br>
Another way is to use Neutron API to query available extensions, by<br>
querying /v2.0/extensions<br>
</blockquote>
<br>
This is actually how we used to control for Nova extensions. I just<br>
went to look at the latest code, though, and while I see the tempest.services.compute.json.<u></u>extensions_client.<u></u>ExtensionsClientJSON.is_<u></u>enabled()<br>
method exists, I don't see it called any more :(<br>
<br>
<a href="https://github.com/openstack/tempest/blob/master/tempest/services/compute/json/extensions_client.py#L36" target="_blank">https://github.com/openstack/<u></u>tempest/blob/master/tempest/<u></u>services/compute/json/<u></u>extensions_client.py#L36</a><br>

<br>
Instead, it looks like a bunch of variables have been added to the<br>
Tempest configuration file that are then checked to see if an<br>
extension should be tested:<br>
<br>
<a href="https://github.com/openstack/tempest/blob/master/tempest/api/compute/admin/test_flavors_extra_specs.py#L39" target="_blank">https://github.com/openstack/<u></u>tempest/blob/master/tempest/<u></u>api/compute/admin/test_<u></u>flavors_extra_specs.py#L39</a><br>

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This will return the list of currently loaded extensions, from which<br>
extension aliases can be easily extracted; these values can then be used<br>
to conditionally skip tests. This Neutron query can either be done each<br>
time an API test class is initialised  or just once - by storing in<br>
memory the list of enabled extensions. If you deem the last approach<br>
reasonable, I'd be happy to provide some code for it. I see many patches<br>
pushed into tempest without an accompanying blueprint/bug; should I<br>
register anyway a blueprint for this work?<br>
</blockquote>
<br>
I would fully support getting rid of tempest configuration file<br>
variables that "enable" these tests and instead just use the<br>
is_enabled() method that checks a memoized list of extensions pulled<br>
from the /extensions resource to determine whether a test should be<br>
run.<br>
<br>
</blockquote>
<br>
We've actually been going the opposite direction in tempest on purpose. The<br>
concern with auto discovery is that if there is a bug we might end up masking<br>
it if something were to go wrong. With auto discovery we can't tell exactly<br>
what is supposed to be run, so if a test is skipped in the >1000 tests because<br>
something went wrong with auto-discovery it'd be very difficult to tell. By<br>
explicitly stating up front in the config what is enabled we know what is<br>
expected to run. Granted this does shift the burden to devstack (or whatever<br>
else you're using to configure tempest) to set this up properly.<br>
<br>
Jay, I originally agreed with you that we can auto-discover things nicely and<br>
trim down the config file. But, we had a couple cases where we found things not<br>
running as expected in the gate and when we fixed it the tests didn't work.<br>
</blockquote>
<br></div></div>
Hi Matt, thanks for sharing the above history. I can see your point and understand the rationale behind the change in direction.<br>
<br>
One thing that might be nice is to make the tempest configuration variables that switch on/off these extension tests consistently named. It's tough right now to scan the tempest config file and try to determine which config options refer to extensions... some use "ENABLED", others use "AVAILABLE", none of them mention extension or have "extension" or "ext" prefixes, etc.<br>

<br>
Best,<br>
-jay<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>