1)Adding 'image_is_advanced' option to tempest config, so you can
run specific tests with images that are not cirros.
2)Adding decorator to run 'subport_connectivity' test with such
image for VLAN aware VM feature.
3)Configuring gate to run trunk test with ubuntu image only
4) Updating release notes and TESTING.rst with the change
Change-Id: Ie15b0e79c6ea320322b2815fb8afbc8ec95f853a
This patch introduces support for requests where the user does
not know the segmentation details of a subport and by specifying
segmentation_type=inherit will let the trunk plugin infer these
details from the network to which the subport is connected to, thus
ignoring the segmentation_id in case it were to be specified.
This type of request is currently expected to have correct results
when the network segmentation type is 'vlan', and the network has
only one segment (provider-net extension use case).
DocImpact: Extend trunk documentation to include Ironic use case.
Closes-bug: #1648129
Depends-on: Ib510aade1716e6ca92940b85245eda7d0c84a070
Change-Id: I3be2638fddf3a9723dd852a3f9ea9f64eb1d0dd6
The MTU of VLAN subinterfaces must not be greater than
MTU of the trunk port. This commit adds API tests that
check that API follows theses guidelines
Change-Id: Ib40c4d44a97b6c9183d48e79383d88dbf2c952db
Partially-Implements: blueprint vlan-aware-vms
Those features are available only when allow_sorting and
allow_pagination options are enabled (the current default is False).
They don't depend on plugin support, because when plugins don't
implement them natively, emulated mode is applied by API router itself.
So to make it plugin agnostic, we introduce a way to register custom
per-extension checks to override support detection for cases like that
one.
Now that we have a way to detect support for those features via API,
there is little reason to keep tempest configuration options to enable
those features. Instead, just inspect [network-feature-enabled]
api_extensions option in tempest.conf.
Now that DEFAULT_ALLOW_SORTING/DEFAULT_ALLOW_PAGINATION constants are
used in a single place only (in allow_sorting/allow_pagination
definitions), removed them and replaced with a literal.
Added first in-tree API tests for /extensions entry point.
DocImpact Update API documentation to cover new extensions.
APIImpact Document the new extensions.
Related-Bug: #1566514
Change-Id: I0aaaa037a8ad52060a68dd75c0a1accc6add238e
These are the very first API tests in the tree to cover those features.
The test is implemented in a generic way that will hopefully ease its
adoption for other resources.
Sadly, those tests cannot pass on every neutron cloud, at least until we
enable those API features by default and remove options to disable the
features.
There is no way to determine, via neutron API, whether cloud supports
those features. To work around that, we introduce two new tempest
options that determine whether tests that rely on sorting or pagination
should be executed. Those options are set in post-extra phase because
configure_tempest resets any configuration made during post-config.
Also bump resource quotas x10 times since default quotas are now not
enough, at least for network resource that is now under sorting and
pagination testing.
Related-Bug: #1566514
Change-Id: I5e68f471a641a34100aba31cb2c4a815c7220014
Tempest commit ed6e586b9f8f0ada10af7711f297afa01b2b7754
changed configuration options defined in Tempest from
tenant to project. Currently we use Tempest from PyPI,
and since there hasn't yet been a Tempest release with
the change that breaks us, we're still safe, however the
next release will break us, so let's be ready for it.
Long term I think the correct thing to do would be to
define new options used exclusively in the Neutron tree.
Change-Id: I054b94a43d900e42872a9cb28d33a3ed45e14779
A while ago we copied Tempest networking API tests in to the
Neutron repo, and along came thousands of lines of code of Tempest
testing infrastructure (neutron.tests.tempest). For a while we
periodically refreshed our fork via:
tools/copy_api_tests_from_tempest.sh
I think it's time we move away from that model by eliminating
the fork. We do this by deleting unused code and importing the
rest from tempest_lib. There's some Tempest code still not
moved from Tempest to tempest_lib in tempest.common. I think
it's preferable to import that code than to copy it, and Tempest
cores mostly agree. Manila and Ironic also do the same.
To be able to import from tempest I added it as a requirement:
Since Tempest is not on PyPi, I had to get it from git. Only the api
tests environment needs Tempest, so instead of adding it to
test-requirements, I added it specifically to the api and
api-constraints venvs.
neutron.tests.tempest.test and neutron.tests.tempest.common.*
still remain. These are tighly coupled with one another, and
sadly since Neutron forked Tempest code, Tempest has made significant
changes to those files that also require changes to the test files.
I aim to get rid of the Neutron fork of these files in a follow up
change.
Also fixed import grouping in test files so that it's std libs,
3rd party libs, and then Neutron code.
* Removed neutron.tests.tempest.config:
- We only added one option after the fork. I created a new group
called 'neutron_plugin_options' and moved the new option to that
group. This is in preperation for the Tempest plugin architecture,
where you're supposed to add new config options to a new group
and not to existing configuration groups. Note that this is
obviously a backward incompatible change, but it's to an option
added in the same cycle.
* Removed neutron.tests.tempest.test and neutron.tests.tempest.common.
- This introduced an API change to the way we access Keystone,
which required mechanical changes to a few tests (create_tenant
calls need a different client now).
- The way Tempest manages primary, admin and alternative tenant
credentials was changed after we forked, which required another
mechanical change to a few tests.
* Cut all of the Keystone clients we don't need. We only need
to create/delete tenants, the other clients were used in Tempest by
actual Keystone tests.
* Changed neutron.tests.api.base.BaseNetworkTest:
- Re-implemented get_client_manager so that it returns the Neutron
clients manager and not the one in the Tempest repo.
- Updated it from the Tempest repo so that it uses the new way
to manage credentials (Since it now uses the Tempest test base
class and not our out of date forked copy).
Change-Id: I4f9193dfe26f2d36985cb480a98709ec182a2f7b
Patch https://review.openstack.org/#/c/256164/
broke the Neutron API job by unsetting Tempest configuration
values that were unused by Tempest, but used by Neutron's fork
of Tempest. This patch copies credentials from the 'auth' section
to the 'identity' section.
The longer term plan is detailed here:
https://etherpad.openstack.org/p/neutron-tempest-defork
TL;DR: Removed overlap of tests between the Tempest and Neutron
repos, then use Tempest's plugin architecture for the tests that
will remain in the Neutron repo.
Change-Id: Ieb396cfd17f9cb66776ead11e7f760c1c26a0b08
The constants of log levels were added in the 1.8 version of
the oslo.log library. So we can replace all usage of system
logging module with log module from oslo.log.
Change-Id: I2992df0bec6337aefa8a75d4853b132bd134fa42
Closes-Bug: 1481370
It's mostly a matter of changing imports to a new location.
Non-obvious changes needed:
* pass overwrite= argument to oslo_context since oslo.log reads context
from its thread local store and not local.store from incubator
* don't store context at local.store now that there is no code that
would consume it
* LOG.deprecated() -> versionutils.report_deprecated_feature()
* dropped LOG.audit check from hacking rule since now the method does
not exist
* WritableLogger is now located in oslo_log.loggers
Dropped log module from the tree. Also dropped local module that is now
of no use (and obsolete, as per oslo team).
Added versionutils back to openstack-common.conf since now we use the
module directly from neutron code and not just as a dependency of some
other oslo-incubator module.
Note: tempest tests are expected to be broken now, so instead of fixing
all the oslo.log related issues for the subtree in this patch, I only
added TODOs with directions for later fix.
Closes-Bug: #1425013
Change-Id: I310e059a815377579de6bb2aa204de168e72571e
Dongcan Ye