[openstack-dev] [devstack] Need some suggestion for a patch on liberty branch

[Bruce Tan]

Hi all,
I am writing to ask suggestion about how to move one patch [1] forward.

This patch is to fix a problem that tempest configuration on liberty is 
not setting "api_extensions", and any test case that verifies API 
extensions NOT on Liberty will get a FALSE POSITIVE (because we used 
"all" in configuration instead of listing all available extensions 
explicitly), and lead to test failure.

The same issue is also on Mitaka, and the counterpart [2] is merged.
(Maybe I should have reported such issues formally as a bug in the first 
place)


This patch has being waiting for review for more than a month, and 
another patch (adding new test cases to Tempest) depending on it got 
workflow one month ago but had to wait for this one to get merged.


I understand that Liberty is not our priority, and it will be EOL soon. 
So I am not sure if I would continue pursuing the patch getting merged, 
or should I wait until Liberty is EOL so that liberty tests get removed 
from Jenkins?


Thank you in advance.

[1] : https://review.openstack.org/#/c/380066/
[2] : https://review.openstack.org/#/c/386886/

--
Best regards,
Bruce Tan


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tempest] Test case for new feature failed in Jenkins check against old release

[Bruce Tan]

Hello everyone,

I am having a problem writing/updating a test case to verify some new
feature (in my case, the "description" field for a network).

Acoording to Tempest Coding Guide[1], I am supposed to check if the
related feature is there by @test.requires_ext() like this:
@test.requires_ext(extension="standard-attr-description",
   service="network")

And according to the same doc,
> When running a test that requires a certain "feature" in the target
> cloud, if that feature is missing we should fail, because either the
> test configuration is invalid, or the cloud is broken and the expected
> "feature" is not there even if the cloud was configured with it.


However, my patch[2] got a "-1" from Jenkins because one check
("gate-tempest-dsvm-neutron-full-ubuntu-trusty-liberty") failed. The
reason for failing, I think, is just what I quoted above: the
tempest.conf[3]  file is configured as
  [network-feature-enabled]api_extensions = all
which means any api_extension is supported; but the feature I am
testing is obviously not there in Liberty, so the API doesn't accept
"description" field, and the test case failed.

So my question is, what did I do wrong? Is there some other way
to skip the case for older releases? Or, maybe we shouldn't use
"api_extensions=all" (explicitly list all extensions instead, which
takes some effort obviously) in the configuration file?

Thank you in advance.

[1] 
http://docs.openstack.org/developer/tempest/HACKING.html#new-tests-for-new-features

[2] https://review.openstack.org/#/c/374645/
[3]
http://logs.openstack.org/45/374645/2/check/gate-tempest-dsvm-neutron-full-ubuntu-trusty-liberty/31bb416/logs/tempest_conf.txt.gz


--
Bruce Tan


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev