On 10/17/2013 08:46 AM, Salvatore Orlando wrote:
Hi,
in the discussion for patch https://review.openstack.org/#/c/50880/ Sean
asked a very reasonable question:
"so are all these [Neutron] extensions always loaded on all
environments? If not, how are we detecting which are?"
So far we've been relying on devstack-gate setup, I think. If the
extension is enabled by devstack-gate, then you can add the test. This
would make sense if tempest is used exclusively by the upstream gate
jobs, which however appears not to be the case. It should therefore be
possible to select which tests should be run according to currently
enabled Neutron extensions, which depend on core and service plugins
One way to solve this issue would be to use tempest configuration
variables; while this is the simplest approach, there are already 25
extensions in Neutron, not counting plugin-specific extensions. This
number can only grow in future releases, so I have a few concerns about
maintainability of this approach because of the high number of
configuration variables.
Another way is to use Neutron API to query available extensions, by
querying /v2.0/extensions
This is actually how we used to control for Nova extensions. I just went
to look at the latest code, though, and while I see the
tempest.services.compute.json.extensions_client.ExtensionsClientJSON.is_enabled()
method exists, I don't see it called any more :(
https://github.com/openstack/tempest/blob/master/tempest/services/compute/json/extensions_client.py#L36
Instead, it looks like a bunch of variables have been added to the
Tempest configuration file that are then checked to see if an extension
should be tested:
https://github.com/openstack/tempest/blob/master/tempest/api/compute/admin/test_flavors_extra_specs.py#L39
This will return the list of currently loaded extensions, from which
extension aliases can be easily extracted; these values can then be used
to conditionally skip tests. This Neutron query can either be done each
time an API test class is initialised or just once - by storing in
memory the list of enabled extensions. If you deem the last approach
reasonable, I'd be happy to provide some code for it. I see many patches
pushed into tempest without an accompanying blueprint/bug; should I
register anyway a blueprint for this work?
I would fully support getting rid of tempest configuration file
variables that "enable" these tests and instead just use the
is_enabled() method that checks a memoized list of extensions pulled
from the /extensions resource to determine whether a test should be run.
Best,
-jay
Regards,
Salvatore
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
