Browse Source

Remove code from this repository

Networking-ovn code has been moved to Neutron.

Depends-On: https://review.opendev.org/721565
Depends-On: https://review.opendev.org/723072
Related-Blueprint: neutron-ovn-merge

Change-Id: Iaec6b21ef44090e76152adb4dd63ae093502bd92
changes/74/715174/3
Maciej Józefczyk 3 months ago
committed by Andreas Jaeger
parent
commit
0f98803fdf
100 changed files with 2 additions and 44564 deletions
  1. +0
    -7
      .coveragerc
  2. +0
    -62
      .gitignore
  3. +0
    -3
      .mailmap
  4. +0
    -114
      .pylintrc
  5. +0
    -3
      .stestr.conf
  6. +0
    -8
      .testr.conf
  7. +0
    -13
      CONTRIBUTING.rst
  8. +0
    -4
      HACKING.rst
  9. +0
    -176
      LICENSE
  10. +2
    -20
      README.rst
  11. +0
    -574
      TESTING.rst
  12. +0
    -2
      babel.cfg
  13. +0
    -29
      devstack/README.rst
  14. +0
    -83
      devstack/computenode-local.conf.sample
  15. +0
    -42
      devstack/db-local.conf.sample
  16. +0
    -107
      devstack/devstackgaterc
  17. +0
    -1
      devstack/files/debs/networking_ovn
  18. +0
    -1
      devstack/files/rpms/networking_ovn
  19. +0
    -610
      devstack/lib/networking-ovn
  20. +0
    -22
      devstack/lib/octavia
  21. +0
    -180
      devstack/lib/ovn
  22. +0
    -169
      devstack/local.conf.sample
  23. +0
    -17
      devstack/network_utils.sh
  24. +0
    -15
      devstack/override-defaults
  25. +0
    -42
      devstack/ovn-octavia-provider.conf.sample
  26. +0
    -82
      devstack/plugin.sh
  27. +0
    -46
      devstack/upgrade/resources.sh
  28. +0
    -18
      devstack/upgrade/settings
  29. +0
    -100
      devstack/upgrade/upgrade.sh
  30. +0
    -42
      devstack/vtep-local.conf.sample
  31. +0
    -10
      doc/requirements.txt
  32. +0
    -0
      doc/source/_static/.placeholder
  33. +0
    -108
      doc/source/admin/containers.rst
  34. +0
    -26
      doc/source/admin/dpdk.rst
  35. +0
    -102
      doc/source/admin/features.rst
  36. +0
    -2849
      doc/source/admin/figures/ovn-east-west-2.svg
  37. +0
    -2850
      doc/source/admin/figures/ovn-east-west-3.svg
  38. +0
    -2779
      doc/source/admin/figures/ovn-east-west.svg
  39. +0
    -3836
      doc/source/admin/figures/ovn-l3ha-bfd-3gw.svg
  40. +0
    -2599
      doc/source/admin/figures/ovn-l3ha-bfd-failover.svg
  41. +0
    -2516
      doc/source/admin/figures/ovn-l3ha-bfd.svg
  42. +0
    -3090
      doc/source/admin/figures/ovn-north-south-distributed-fip.svg
  43. +0
    -2991
      doc/source/admin/figures/ovn-north-south.svg
  44. +0
    -16
      doc/source/admin/index.rst
  45. +0
    -211
      doc/source/admin/loadbalancer.rst
  46. +0
    -70
      doc/source/admin/ovn.rst
  47. BIN
      doc/source/admin/refarch/figures/ovn-architecture1.png
  48. +0
    -1568
      doc/source/admin/refarch/figures/ovn-architecture1.svg
  49. BIN
      doc/source/admin/refarch/figures/ovn-compute1.png
  50. +0
    -982
      doc/source/admin/refarch/figures/ovn-compute1.svg
  51. BIN
      doc/source/admin/refarch/figures/ovn-hw.png
  52. +0
    -1170
      doc/source/admin/refarch/figures/ovn-hw.svg
  53. BIN
      doc/source/admin/refarch/figures/ovn-services.png
  54. +0
    -860
      doc/source/admin/refarch/figures/ovn-services.svg
  55. +0
    -774
      doc/source/admin/refarch/launch-instance-provider-network.rst
  56. +0
    -757
      doc/source/admin/refarch/launch-instance-selfservice-network.rst
  57. +0
    -656
      doc/source/admin/refarch/provider-networks.rst
  58. +0
    -309
      doc/source/admin/refarch/refarch.rst
  59. +0
    -855
      doc/source/admin/refarch/routers.rst
  60. +0
    -517
      doc/source/admin/refarch/selfservice-networks.rst
  61. +0
    -181
      doc/source/admin/routing.rst
  62. +0
    -42
      doc/source/admin/troubleshooting.rst
  63. +0
    -8
      doc/source/admin/tutorial.rst
  64. +0
    -100
      doc/source/conf.py
  65. +0
    -30
      doc/source/configuration/index.rst
  66. +0
    -6
      doc/source/configuration/ml2_conf.rst
  67. +0
    -6
      doc/source/configuration/networking_ovn_metadata_agent.rst
  68. +0
    -9
      doc/source/configuration/samples/ml2_conf.rst
  69. +0
    -9
      doc/source/configuration/samples/networking_ovn_metadata_agent.rst
  70. +0
    -4
      doc/source/contributor/contributing.rst
  71. +0
    -184
      doc/source/contributor/design/acl_optimizations.rst
  72. +0
    -266
      doc/source/contributor/design/data_model.rst
  73. +0
    -440
      doc/source/contributor/design/database_consistency.rst
  74. +0
    -140
      doc/source/contributor/design/distributed_ovsdb_events.rst
  75. +0
    -16
      doc/source/contributor/design/index.rst
  76. +0
    -163
      doc/source/contributor/design/l3_ha_rescheduling.rst
  77. +0
    -313
      doc/source/contributor/design/loadbalancer.rst
  78. +0
    -360
      doc/source/contributor/design/metadata_api.rst
  79. +0
    -50
      doc/source/contributor/design/native_dhcp.rst
  80. +0
    -81
      doc/source/contributor/design/ovn_worker.rst
  81. +0
    -12
      doc/source/contributor/index.rst
  82. +0
    -655
      doc/source/contributor/testing.rst
  83. +0
    -26
      doc/source/contributor/testing/testing.rst
  84. +0
    -18
      doc/source/contributor/vagrant/index.rst
  85. +0
    -27
      doc/source/contributor/vagrant/prerequisites.rst
  86. +0
    -104
      doc/source/contributor/vagrant/sparse-architecture.rst
  87. +0
    -111
      doc/source/faq/index.rst
  88. +0
    -53
      doc/source/index.rst
  89. +0
    -1596
      doc/source/install/figures/ovn-initial-resources.svg
  90. +0
    -3175
      doc/source/install/figures/tripleo-ovn-arch.svg
  91. +0
    -14
      doc/source/install/index.rst
  92. +0
    -343
      doc/source/install/manual.rst
  93. +0
    -368
      doc/source/install/migration.rst
  94. +0
    -284
      doc/source/install/tripleo.rst
  95. +0
    -6
      etc/oslo-config-generator/ml2_conf.ini
  96. +0
    -6
      etc/oslo-config-generator/networking_ovn_metadata_agent.ini
  97. +0
    -152
      lower-constraints.txt
  98. +0
    -43
      migration/README.rst
  99. +0
    -37
      migration/hosts.sample
  100. +0
    -33
      migration/infrared/tripleo-ovn-migration/README.rst

+ 0
- 7
.coveragerc View File

@@ -1,7 +0,0 @@
[run]
branch = True
source = networking_ovn
omit = networking_ovn/tests/*

[report]
ignore_errors = True

+ 0
- 62
.gitignore View File

@@ -1,62 +0,0 @@
*.py[cod]

# C extensions
*.so

# Packages
*.egg
*.egg-info
dist
build
eggs
parts
bin
var
sdist
develop-eggs
lib
lib64

# Installer logs
pip-log.txt

# Unit test / coverage reports
nosetests.xml
.stestr

# Translations
*.mo

# Complexity
output/*.html
output/*/index.html

# Documentation
doc/build
doc/source/_static/config_samples/*.sample
etc/**/*.sample

# pbr generates these
AUTHORS
ChangeLog

# Editors
*~
*.sw?

# Hidden directories
/.*
!/.coveragerc
!/.gitignore
!/.gitreview
!/.mailmap
!/.pylintrc
!/.stestr.conf
!/.testr.conf
!/devstack/lib

# Vagrant directory
vagrant/.vagrant

# Files created by releasenotes build
releasenotes/build

+ 0
- 3
.mailmap View File

@@ -1,3 +0,0 @@
# Format is:
# <preferred e-mail> <other e-mail 1>
# <preferred e-mail> <other e-mail 2>

+ 0
- 114
.pylintrc View File

@@ -1,114 +0,0 @@
# The format of this file isn't really documented; just use --generate-rcfile
[MASTER]
# Add <file or directory> to the black list. It should be a base name, not a
# path. You may set this option multiple times.
ignore=.git,tests

[MESSAGES CONTROL]
# TODO: This list is copied from neutron, the options which do not need to be
# suppressed have been already removed, some of the remaining options will be
# removed by code adjustment.
disable=
# "F" Fatal errors that prevent further processing
import-error,
# "I" Informational noise
# "E" Error for important programming issues (likely bugs)
no-member,
# "W" Warnings for stylistic problems or minor programming issues
abstract-method,
arguments-differ,
attribute-defined-outside-init,
broad-except,
dangerous-default-value,
fixme,
global-statement,
no-init,
protected-access,
redefined-builtin,
redefined-outer-name,
signature-differs,
unused-argument,
unused-import,
unused-variable,
useless-super-delegation,
# "C" Coding convention violations
bad-continuation,
invalid-name,
len-as-condition,
misplaced-comparison-constant,
missing-docstring,
superfluous-parens,
ungrouped-imports,
wrong-import-order,
# "R" Refactor recommendations
duplicate-code,
no-else-return,
no-self-use,
too-few-public-methods,
too-many-ancestors,
too-many-arguments,
too-many-branches,
too-many-instance-attributes,
too-many-lines,
too-many-locals,
too-many-public-methods,
too-many-return-statements,
too-many-statements,
inconsistent-return-statements,
useless-object-inheritance,
too-many-nested-blocks,
too-many-boolean-expressions,
not-callable,
# new for python3 version of pylint
chained-comparison,
consider-using-dict-comprehension,
consider-using-in,
consider-using-set-comprehension,
unnecessary-pass,
useless-object-inheritance


[BASIC]
# Variable names can be 1 to 31 characters long, with lowercase and underscores
variable-rgx=[a-z_][a-z0-9_]{0,30}$

# Argument names can be 2 to 31 characters long, with lowercase and underscores
argument-rgx=[a-z_][a-z0-9_]{1,30}$

# Method names should be at least 3 characters long
# and be lowercased with underscores
method-rgx=([a-z_][a-z0-9_]{2,}|setUp|tearDown)$

# Module names matching
module-rgx=(([a-z_][a-z0-9_]*)|([A-Z][a-zA-Z0-9]+))$

# Don't require docstrings on tests.
no-docstring-rgx=((__.*__)|([tT]est.*)|setUp|tearDown)$

[FORMAT]
# Maximum number of characters on a single line.
max-line-length=79

[VARIABLES]
# List of additional names supposed to be defined in builtins. Remember that
# you should avoid to define new builtins when possible.
additional-builtins=

[CLASSES]
# List of interface methods to ignore, separated by a comma.
ignore-iface-methods=

[IMPORTS]
# Deprecated modules which should not be used, separated by a comma
deprecated-modules=
# should use oslo_serialization.jsonutils
json

[TYPECHECK]
# List of module names for which member attributes should not be checked
ignored-modules=six.moves,_MovedItems

[REPORTS]
# Tells whether to display a full report or only the messages
reports=no


+ 0
- 3
.stestr.conf View File

@@ -1,3 +0,0 @@
[DEFAULT]
test_path=${OS_TEST_PATH:-./networking_ovn/tests/unit}
top_dir=./

+ 0
- 8
.testr.conf View File

@@ -1,8 +0,0 @@
[DEFAULT]
test_command=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
OS_LOG_CAPTURE=1 \
${PYTHON:-python} -m subunit.run discover -t ./ ${OS_TEST_PATH:-./networking_ovn/tests/unit} $LISTOPT $IDOPTION
test_id_option=--load-list $IDFILE
test_list_option=--list

+ 0
- 13
CONTRIBUTING.rst View File

@@ -1,13 +0,0 @@
If you would like to contribute to the development of OpenStack,
you must follow the steps in this page:
https://docs.openstack.org/infra/manual/developers.html

Once those steps have been completed, changes to OpenStack
should be submitted for review via the Gerrit tool, following
the workflow documented at:
https://docs.openstack.org/infra/manual/developers.html#development-workflow

Pull requests submitted through GitHub will be ignored.

Bugs should be filed on Launchpad, not GitHub:
https://bugs.launchpad.net/networking-ovn

+ 0
- 4
HACKING.rst View File

@@ -1,4 +0,0 @@
networking-ovn Style Commandments
===============================================

Read the OpenStack Style Commandments https://docs.openstack.org/hacking/latest/

+ 0
- 176
LICENSE View File

@@ -1,176 +0,0 @@

Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions.

"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.

"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.

"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.

"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.

"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.

"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.

"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).

"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.

"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."

"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.

2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.

3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.

4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:

(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and

(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and

(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and

(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.

You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.

5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.

6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.

7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.

8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.


+ 2
- 20
README.rst View File

@@ -2,23 +2,5 @@
networking-ovn - OpenStack Neutron integration with OVN
=========================================================

OVN provides virtual networking for Open vSwitch and is a component of the Open
vSwitch project. This project provides integration between OpenStack Neutron
and OVN.

* Free software: Apache license
* Source: https://opendev.org/openstack/networking-ovn
* Bugs: https://bugs.launchpad.net/networking-ovn
* Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
* IRC: #openstack-neutron-ovn on Freenode.
* Docs: https://docs.openstack.org/networking-ovn/latest

Team and repository tags
------------------------

.. image:: https://governance.openstack.org/tc/badges/networking-ovn.svg
:target: https://governance.openstack.org/tc/reference/tags/index.html

* Release notes for the project can be found at:
https://docs.openstack.org/releasenotes/networking-ovn/
Networking-OVN project has been merged with Neutron.
It can now be found at [https://opendev.org/openstack/neutron](https://opendev.org/openstack/neutron)

+ 0
- 574
TESTING.rst View File

@@ -1,574 +0,0 @@
..
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.


Convention for heading levels in OVN devref:
======= Heading 0 (reserved for the title in a document)
------- Heading 1
~~~~~~~ Heading 2
+++++++ Heading 3
''''''' Heading 4
(Avoid deeper levels because they do not render well.)

.. _testing_networking_ovn:

Testing OVN
===========

Why Should You Care
-------------------
There's two ways to approach testing:

1) Write unit tests because they're required to get your patch merged.
This typically involves mock heavy tests that assert that your code is as
written.
2) Putting as much thought into your testing strategy as you do to the rest
of your code. Use different layers of testing as appropriate to provide
high *quality* coverage. Are you touching an agent? Test it against an
actual system! Are you adding a new API? Test it for race conditions
against a real database! Are you adding a new cross-cutting feature?
Test that it does what it's supposed to do when run on a real cloud!

Do you feel the need to verify your change manually? If so, the next few
sections attempt to guide you through OVN's different test infrastructures
to help you make intelligent decisions and best exploit OVN's test
offerings.

Definitions
-----------
We will talk about three classes of tests: unit, functional and integration.
Each respective category typically targets a larger scope of code. Other than
that broad categorization, here are a few more characteristic:

* Unit tests - Should be able to run on your laptop, directly following a
'git clone' of the project. The underlying system must not be mutated,
mocks can be used to achieve this. A unit test typically targets a function
or class.
* Functional tests - Run against a pre-configured environment
(tools/configure_for_func_testing.sh). Typically test a component
such as an agent using no mocks.
* Integration tests - Run against a running cloud, often target the API level,
but also 'scenarios' or 'user stories'. You may find such tests in
the Tempest, Rally and
neutron-tempest-plugin(neutron_tempest_plugin/api|scenario) projects.

Tests in the OVN tree are typically organized by the testing infrastructure
used, and not by the scope of the test. For example, many tests under the
'unit' directory invoke an API call and assert that the expected output was
received. The scope of such a test is the entire OVN server stack,
and clearly not a specific function such as in a typical unit test.

Testing Frameworks
------------------

The different frameworks are listed below. The intent is to list the
capabilities of each testing framework as to help the reader understand when
should each tool be used. Remember that when adding code that touches many
areas of OVN, each area should be tested with the appropriate framework.
Overlap between different test layers is often desirable and encouraged.

Unit Tests
~~~~~~~~~~

Unit tests (networking_ovn/tests/unit/) are meant to cover as much code as
possible. They are designed to test the various pieces of the OVN tree to
make sure any new changes don't break existing functionality. Unit tests have
no requirements nor make changes to the system they are running on. They use
an in-memory sqlite database to test DB interaction.

At the start of each test run:

* RPC listeners are mocked away.
* The fake Oslo messaging driver is used.

At the end of each test run:

* Mocks are automatically reverted.
* The in-memory database is cleared of content, but its schema is maintained.
* The global Oslo configuration object is reset.

The unit testing framework can be used to effectively test database interaction,
for example, OVN supports code to bump object revision numbers.
Its test looks like this:

.. code-block:: python

def test_bump_revision(self):
db_rev.create_initial_revision(self.net['id'], constants.TYPE_NETWORKS,
self.session)
self.net['revision_number'] = 123
db_rev.bump_revision(self.net, constants.TYPE_NETWORKS)
row = db_rev.get_revision_row(self.net['id'])
self.assertEqual(123, row.revision_number)

It creates a network with an initial revision number, invokes the method under
test to change the revision number, and asserts it has changed. The test has
many things going for it:

* It targets the method under test correctly, not taking on a larger scope
than is necessary.
* It does not use mocks to assert that methods were called, it simply
invokes the method and asserts its output (In this case, that the get
method returns the object).

This is allowed by the fact that the method was built to be testable -
The method has clear input and output with no side effects.

You can get oslo.db to generate a file-based sqlite database by setting
OS_TEST_DBAPI_ADMIN_CONNECTION to a file based URL as described in `this
mailing list post`__. This file will be created but (confusingly) won't be the
actual file used for the database. To find the actual file, set a break point
in your test method and inspect self.engine.url.

__ file-based-sqlite_

.. code-block:: shell

$ OS_TEST_DBAPI_ADMIN_CONNECTION=sqlite:///sqlite.db .tox/py37/bin/python -m \
testtools.run networking_ovn.tests.unit...
...
(Pdb) self.engine.url
sqlite:////tmp/iwbgvhbshp.db

Now, you can inspect this file using sqlite3.

.. code-block:: shell

$ sqlite3 /tmp/iwbgvhbshp.db

Functional Tests
~~~~~~~~~~~~~~~~

Functional tests (networking_ovn/tests/functional/) are intended to
validate actual system interaction. Mocks should be used sparingly,
if at all. Care should be taken to ensure that existing system
resources are not modified and that resources created in tests are
properly cleaned up both on test success and failure.

Let's examine the benefits of the functional testing framework.
Neutron offers a library called 'ip_lib' that wraps around the 'ip' binary.
One of its methods is called 'device_exists' which accepts a device name
and a namespace and returns True if the device exists in the given namespace.
It's easy building a test that targets the method directly, and such a test
would be considered a 'unit' test. However, what framework should such a test
use? A test using the unit tests framework could not mutate state on the system,
and so could not actually create a device and assert that it now exists. Such
a test would look roughly like this:

* It would mock 'execute', a method that executes shell commands against the
system to return an IP device named 'foo'.
* It would then assert that when 'device_exists' is called with 'foo', it
returns True, but when called with a different device name it returns False.
* It would most likely assert that 'execute' was called using something like:
'ip link show foo'.

The value of such a test is arguable. Remember that new tests are not free,
they need to be maintained. Code is often refactored, reimplemented and
optimized.

* There are other ways to find out if a device exists (Such as
by looking at '/sys/class/net'), and in such a case the test would have
to be updated.
* Methods are mocked using their name. When methods are renamed, moved or
removed, their mocks must be updated. This slows down development for
avoidable reasons.
* Most importantly, the test does not assert the behavior of the method. It
merely asserts that the code is as written.

When adding a functional test for 'device_exists', several framework level
methods were added. These methods may now be used by other tests as well.
One such method creates a virtual device in a namespace,
and ensures that both the namespace and the device are cleaned up at the
end of the test run regardless of success or failure using the 'addCleanup'
method. The test generates details for a temporary device, asserts that
a device by that name does not exist, creates that device, asserts that
it now exists, deletes it, and asserts that it no longer exists.
Such a test avoids all three issues mentioned above if it were written
using the unit testing framework.

Functional tests are also used to target larger scope, such as agents.
Many good examples exist: See the OVS, L3 and DHCP agents functional tests.
Such tests target a top level agent method and assert that the system
interaction that was supposed to be performed was indeed performed.
For example, to test the DHCP agent's top level method that accepts network
attributes and configures dnsmasq for that network, the test:

* Instantiates an instance of the DHCP agent class (But does not start its
process).
* Calls its top level function with prepared data.
* Creates a temporary namespace and device, and calls 'dhclient' from that
namespace.
* Assert that the device successfully obtained the expected IP address.

Test exceptions
+++++++++++++++

Test networking_ovn.tests.functional.test_ovn_db_resources.TestPortSecurity.\
test_port_security_port_group is currently skipped if port groups are not
supported in the northbound API. If the API meets the test requirement then
the test is triggered normally.

API Tests
~~~~~~~~~

API tests (neutron-tempest-plugin/neutron_tempest_plugin/api/) are
intended to ensure the function
and stability of the Neutron API. As much as possible, changes to
this path should not be made at the same time as changes to the code
to limit the potential for introducing backwards-incompatible changes,
although the same patch that introduces a new API should include an API
test.

Since API tests target a deployed OVN daemon that is not test-managed,
they should not depend on controlling the runtime configuration
of the target daemon. API tests should be black-box - no assumptions should
be made about implementation. Only the contract defined by Neutron's REST API
should be validated, and all interaction with the daemon should be via
a REST client.

The neutron-tempest-plugin/neutron_tempest_plugin directory was copied from the
Tempest project around the Kilo timeframe. At the time, there was an overlap of
tests between the Tempest and Neutron repositories. This overlap was then
eliminated by carving out a subset of resources that belong to Tempest, with
the rest in Neutron.

API tests that belong to Tempest deal with a subset of OVN's resources:

* Port
* Network
* Subnet
* Security Group
* Router
* Floating IP

These resources were chosen for their ubiquity. They are found in most
Neutron deployments regardless of plugin, and are directly involved in the
networking and security of an instance. Together, they form the bare minimum
needed by Neutron.

This is excluding extensions to these resources (For example: Extra DHCP
options to subnets, or snat_gateway mode to routers) that are not mandatory
in the majority of cases.

Tests for other resources should be contributed to the Neutron repository.
Scenario tests should be similarly split up between Tempest and Neutron
according to the API they're targeting.

To create an API test, the testing class must at least inherit from
neutron_tempest_plugin.api.base.BaseNetworkTest base class. As some of tests
may require certain extensions to be enabled, the base class provides
``required_extensions`` class attribute which can be used by subclasses to
define a list of required extensions for particular test class.

Scenario Tests
~~~~~~~~~~~~~~

Scenario tests (neutron-tempest-plugin/neutron_tempest_plugin/scenario), like
API tests, use the Tempest test infrastructure and have the same requirements.
Guidelines for writing a good scenario test may be found at the Tempest
developer guide:
https://docs.openstack.org/tempest/latest/field_guide/scenario.html

Scenario tests, like API tests, are split between the Tempest and Neutron
repositories according to the Neutron API the test is targeting.

Some scenario tests require advanced ``Glance`` images (for example, ``Ubuntu``
or ``CentOS``) in order to pass. Those tests are skipped by default. To enable
them, include the following in ``tempest.conf``:

.. code-block:: ini

[compute]
image_ref = <uuid of advanced image>
[neutron_plugin_options]
image_is_advanced = True

Specific test requirements for advanced images are:

#. ``test_trunk`` requires ``802.11q`` kernel module loaded.

Rally Tests
~~~~~~~~~~~

Rally tests (rally-jobs/plugins) use the `rally <http://rally.readthedocs.io/>`_
infrastructure to exercise an OVN deployment. Guidelines for writing a
good rally test can be found in the
`rally plugin documentation <http://rally.readthedocs.io/en/latest/plugins/>`_.
There are also some examples in tree; the process for adding rally plugins to
OVN requires three steps:

1) write a plugin and place it under rally-jobs/plugins/. This is your rally
scenario;
2) (optional) add a setup file under rally-jobs/extra/. This is any devstack
configuration required to make sure your environment can successfully
process your scenario requests;
3) edit ovn.yaml. This is your scenario 'contract' or SLA.

Development Process
-------------------

It is expected that any new changes that are proposed for merge
come with tests for that feature or code area. Any bugs
fixes that are submitted must also have tests to prove that they stay
fixed! In addition, before proposing for merge, all of the
current tests should be passing.

Structure of the Unit Test Tree
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The structure of the unit test tree should match the structure of the
code tree, e.g. ::

- target module: networking_ovn.agent.metadata.agent

- test module: networking_ovn.tests.unit.agent.metadata.test_agent

Unit test modules should have the same path under networking_ovn/tests/unit/
as the module they target has under networking_ovn/, and their name should be
the name of the target module prefixed by `test_`. This requirement
is intended to make it easier for developers to find the unit tests
for a given module.

The following command can be used to validate whether the unit test
tree is structured according to the above requirements: ::

./tools/check_unit_test_structure.sh

Where appropriate, exceptions can be added to the above script. If
code is not part of the OVN namespace, for example, it's probably
reasonable to exclude their unit tests from the check.


.. note ::

At no time should the production code import anything from testing subtree
(networking_ovn.tests). There are distributions that split out
networking_ovn.tests modules in a separate package that is not installed by
default, making any code that relies on presence of the modules to fail.
For example, RDO is one of those distributions.

Running Tests
-------------

Before submitting a patch for review you should always ensure all tests pass; a
tox run is triggered by the jenkins gate executed on gerrit for each patch
pushed for review.

OVN, like other OpenStack projects, uses `tox`_ for managing the virtual
environments for running test cases. It uses `Testr`_ for managing the running
of the test cases.

Tox handles the creation of a series of `virtualenvs`_ that target specific
versions of Python.

Testr handles the parallel execution of series of test cases as well as
the tracking of long-running tests and other things.

For more information on the standard Tox-based test infrastructure used by
OpenStack and how to do some common test/debugging procedures with Testr,
see this wiki page: https://wiki.openstack.org/wiki/Testr

.. _Testr: https://wiki.openstack.org/wiki/Testr
.. _tox: http://tox.readthedocs.org/en/latest/
.. _virtualenvs: https://pypi.org/project/virtualenv

PEP8 and Unit Tests
~~~~~~~~~~~~~~~~~~~

Running pep8 and unit tests is as easy as executing this in the root
directory of the OVN source code::

tox

To run only pep8::

tox -e pep8

Since pep8 includes running pylint on all files, it can take quite some time
to run. To restrict the pylint check to only the files altered by the latest
patch changes::

tox -e pep8 HEAD~1

To run only pep8, but using the latest code from the upstream neutron
repository instead of the pip installed version from requirements.txt::

tox -e pep8-dev

To run only the unit tests::

tox -e py37

To run only the unit tests, but using the latest code from the upstream
neutron repository instead of the pip installed version from requirements.txt::

tox -e dev

Many changes span across both the OVN and neutron-lib repos, and tox
will always build the test environment using the published module versions
specified in requirements.txt and lower-constraints.txt. To run tox tests
against a different version of neutron-lib, use the TOX_ENV_SRC_MODULES
environment variable to point at a local package repo.

For example, to run against the 'master' branch of neutron-lib::

cd $SRC
git clone https://git.openstack.org/openstack/neutron-lib
cd $OVN_DIR
env TOX_ENV_SRC_MODULES=$SRC/neutron-lib tox -r -e pep8,py37

To run against a change of your own, repeat the same steps, but use the
directory with your changes, not a fresh clone.

To run against a particular gerrit change of the lib (substituting the
desired gerrit refs for this example)::

cd $SRC
git clone https://git.openstack.org/openstack/neutron-lib
cd neutron-lib
git fetch https://git.openstack.org/openstack/neutron-lib refs/changes/13/635313/6 && git checkout FETCH_HEAD
cd $OVN_DIR
env TOX_ENV_SRC_MODULES=$SRC/neutron-lib tox -r -e pep8,py37

Note that the '-r' is needed to re-create the tox virtual envs, and will also
be needed to restore them to standard when not using this method.

Any pip installable package can be overriden with this environment variable,
not just neutron-lib. To specify multiple packages to override, specify them
as a space separated list to TOX_ENV_SRC_MODULES. For example, to override
both neutron and oslo.db::

env TOX_ENV_SRC_MODULES="$SRC/neutron-lib $SRC/neutron $SRC/oslo.db" tox -r -e pep8,py37

Functional Tests
~~~~~~~~~~~~~~~~

To run functional tests that do not require sudo privileges or
specific-system dependencies::

tox -e functional

To run all the functional tests, including those requiring sudo
privileges and system-specific dependencies, the procedure defined by
tools/configure_for_func_testing.sh should be followed.

IMPORTANT: configure_for_func_testing.sh relies on DevStack to perform
extensive modification to the underlying host. Execution of the
script requires sudo privileges and it is recommended that the
following commands be invoked only on a clean and disposable VM.
A VM that has had DevStack previously installed on it is also fine. ::

git clone https://git.openstack.org/openstack-dev/devstack ../devstack
./tools/configure_for_func_testing.sh ../devstack -i
tox -e dsvm-functional

The '-i' option is optional and instructs the script to use DevStack
to install and configure all of OVN's package dependencies. It is
not necessary to provide this option if DevStack has already been used
to deploy OVN to the target host.

API & Scenario Tests
~~~~~~~~~~~~~~~~~~~~

To run the api or scenario tests, deploy Tempest, neutron-tempest-plugin
and OVN with DevStack and then run the following command,
from the tempest directory: ::

$ export DEVSTACK_GATE_TEMPEST_REGEX="networking_ovn"
$ tox -e all-plugin $DEVSTACK_GATE_TEMPEST_REGEX

If you want to limit the amount of tests, or run an individual test,
you can do, for instance: ::

$ tox -e all-plugin neutron_tempest_plugin.api.admin.test_routers_ha
$ tox -e all-plugin neutron_tempest_plugin.api.test_qos.QosTestJSON.test_create_policy

If you want to use special config for OVN, like use advanced images (Ubuntu
or CentOS) testing advanced features, you may need to add config
in tempest/etc/tempest.conf:

.. code-block:: ini

[neutron_plugin_options]
image_is_advanced = True

The Neutron tempest plugin configs are under ``neutron_plugin_options`` scope
of ``tempest.conf``.

Running Individual Tests
~~~~~~~~~~~~~~~~~~~~~~~~

For running individual test modules, cases or tests, you just need to pass
the dot-separated path you want as an argument to it.

For example, the following would run only a single test or test case::

$ tox -e py37 networking_ovn.tests.unit.ovsdb.test_commands
$ tox -e py37 networking_ovn.tests.unit.ovsdb.test_commands.TestAddLRouterCommand
$ tox -e py37 networking_ovn.tests.unit.ovsdb.test_commands.TestAddLRouterCommand.test_lrouter_exists

If you want to pass other arguments to stestr, you can do the following::

$ tox -e py37 -- networking_ovn.tests.unit.ovsdb.test_commands --serial


Coverage
--------

OVN has a fast growing code base and there are plenty of areas that
need better coverage.

To get a grasp of the areas where tests are needed, you can check
current unit tests coverage by running::

$ tox -e cover

Note: The cover command can only show unit test coverage


Debugging
---------

By default, calls to pdb.set_trace() will be ignored when tests
are run. For pdb statements to work, invoke tox as follows::

$ tox -e venv -- python -m testtools.run [test module path]

Tox-created virtual environments (venv's) can also be activated
after a tox run and reused for debugging::

$ tox -e venv
$ . .tox/venv/bin/activate
$ python -m testtools.run [test module path]

Tox packages and installs the OVN source tree in a given venv
on every invocation, but if modifications need to be made between
invocation (e.g. adding more pdb statements), it is recommended
that the source tree be installed in the venv in editable mode::

# run this only after activating the venv
$ pip install --editable .

Editable mode ensures that changes made to the source tree are
automatically reflected in the venv, and that such changes are not
overwritten during the next tox run.

Post-mortem Debugging
~~~~~~~~~~~~~~~~~~~~~

TBD: how to do this with tox.

References
~~~~~~~~~~

.. _file-based-sqlite: http://lists.openstack.org/pipermail/openstack-dev/2016-July/099861.html

+ 0
- 2
babel.cfg View File

@@ -1,2 +0,0 @@
[python: **.py]


+ 0
- 29
devstack/README.rst View File

@@ -1,29 +0,0 @@
======================
Enabling in Devstack
======================

1. Download devstack and networking-ovn::

git clone https://opendev.org/openstack/devstack.git
git clone https://opendev.org/openstack/networking-ovn.git

2. Add networking-ovn to devstack. The minimal set of critical local.conf
additions are the following::

cd devstack
cat << EOF >> local.conf
> enable_plugin networking-ovn https://opendev.org/openstack/networking-ovn
> enable_service ovn-northd
> enable_service ovn-controller
> enable_service networking-ovn-metadata-agent
> EOF

You can also use the provided example local.conf, or look at its contents to
add to your own::

cd devstack
cp ../networking-ovn/devstack/local.conf.sample local.conf

3. run devstack::

./stack.sh

+ 0
- 83
devstack/computenode-local.conf.sample View File

@@ -1,83 +0,0 @@
#
# Sample DevStack local.conf.
#
# This sample file is intended to be used when adding an additional compute node
# to your test environment. It runs a very minimal set of services.
#
# For this configuration to work, you *must* set the SERVICE_HOST option to the
# IP address of the main DevStack host. You must also set HOST_IP to the IP
# address of this host.
#

[[local|localrc]]

DATABASE_PASSWORD=password
RABBIT_PASSWORD=password
SERVICE_PASSWORD=password
SERVICE_TOKEN=password
ADMIN_PASSWORD=password

# Enable devstack spawn logging
LOGFILE=$DEST/logs/stack.sh.log

# The DevStack plugin defaults to using the ovn branch from the official ovs
# repo. You can optionally use a different one. For example, you may want to
# use the latest patches in blp's ovn branch:
#OVN_REPO=https://github.com/blp/ovs-reviews.git
#OVN_BRANCH=ovn

enable_plugin networking-ovn https://opendev.org/openstack/networking-ovn

disable_all_services
enable_service n-cpu
enable_service placement-client
enable_service ovn-controller
enable_service networking-ovn-metadata-agent

# Set this to the address of the main DevStack host running the rest of the
# OpenStack services.
SERVICE_HOST=<IP address of host running everything else>
RABBIT_HOST=$SERVICE_HOST
Q_HOST=$SERVICE_HOST

# How to connect to ovsdb-server hosting the OVN SB database
OVN_SB_REMOTE=tcp:$SERVICE_HOST:6642

# A UUID to uniquely identify this system. If one is not specified, a random
# one will be generated and saved in the file 'ovn-uuid' for re-use in future
# DevStack runs.
#OVN_UUID=

# Whether or not to build custom openvswitch kernel modules from the ovs git
# tree. This is enabled by default. This is required unless your distro kernel
# includes ovs+conntrack support. This support was first released in Linux 4.3,
# and will likely be backported by some distros.
#OVN_BUILD_MODULES=False

HOST_IP=<IP address of current host>
NOVA_VNC_ENABLED=True
NOVNCPROXY_URL=http://$SERVICE_HOST:6080/vnc_lite.html
VNCSERVER_LISTEN=$HOST_IP
VNCSERVER_PROXYCLIENT_ADDRESS=$VNCSERVER_LISTEN

# Skydive
#enable_plugin skydive https://github.com/redhat-cip/skydive.git
#enable_service skydive-agent

# Provider Network
# If you want to enable a provider network instead of the default private
# network after your DevStack environment installation, you *must* set the
# Q_USE_PROVIDER_NETWORKING to True, and give value to both PHYSICAL_NETWORK
# and OVS_PHYSICAL_BRIDGE.
#Q_USE_PROVIDER_NETWORKING=True
#PHYSICAL_NETWORK=providernet
#OVS_PHYSICAL_BRIDGE=br-provider
#PUBLIC_INTERFACE=<public interface>

# If the admin wants to enable this chassis to host gateway routers for
# external connectivity, then set ENABLE_CHASSIS_AS_GW to True.
# Then devstack will set ovn-cms-options with enable-chassis-as-gw
# in Open_vSwitch table's external_ids column.
# If this option is not set on any chassis, all the of them with bridge
# mappings configured will be eligible to host a gateway.
#ENABLE_CHASSIS_AS_GW=False

+ 0
- 42
devstack/db-local.conf.sample View File

@@ -1,42 +0,0 @@
#
# Sample DevStack local.conf.
#
# This sample file is intented to be used for running ovn-northd and the
# OVN DBs on a separate node.
#
# For this configuration to work, you *must* set the SERVICE_HOST option to the
# IP address of the main DevStack host.
#

[[local|localrc]]

DATABASE_PASSWORD=password
RABBIT_PASSWORD=password
SERVICE_PASSWORD=password
SERVICE_TOKEN=password
ADMIN_PASSWORD=password

# Enable devstack spawn logging
LOGFILE=$DEST/logs/stack.sh.log

# The DevStack plugin defaults to using the ovn branch from the official ovs
# repo. You can optionally use a different one. For example, you may want to
# use the latest patches in blp's ovn branch:
#OVN_REPO=https://github.com/blp/ovs-reviews.git
#OVN_BRANCH=ovn

enable_plugin networking-ovn https://opendev.org/openstack/networking-ovn

disable_all_services
enable_service ovn-northd

# A UUID to uniquely identify this system. If one is not specified, a random
# one will be generated and saved in the file 'ovn-uuid' for re-use in future
# DevStack runs.
#OVN_UUID=

# Whether or not to build custom openvswitch kernel modules from the ovs git
# tree. This is enabled by default. This is required unless your distro kernel
# includes ovs+conntrack support. This support was first released in Linux 4.3,
# and will likely be backported by some distros.
#OVN_BUILD_MODULES=False

+ 0
- 107
devstack/devstackgaterc View File

@@ -1,107 +0,0 @@
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.

#
# This script is executed in the tempest-dsvm-networking-ovn
# OpenStack CI job that runs DevStack + tempest. It is also used by the
# rally job. You can find the CI job configuration here:
#
# http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/networking-ovn.yaml
#

OVN_OPTS=$@

OVERRIDE_ENABLED_SERVICES=key,n-api,n-cpu,n-cond,n-sch,n-crt,n-cauth,n-obj,n-api-meta,placement-api,g-api,g-reg,c-sch,c-api,c-vol,rabbit,mysql,dstat,ovn-northd,ovn-controller,q-svc,networking-ovn-metadata-agent,br-ex-tcpdump,br-int-flows,q-trunk,octavia,o-api,o-hk
export OVERRIDE_ENABLED_SERVICES

if [ -z "${RALLY_SCENARIO}" ] ; then
# Only include tempest if this is not a rally job.
export OVERRIDE_ENABLED_SERVICES=${OVERRIDE_ENABLED_SERVICES},tempest
fi
export DEVSTACK_LOCAL_CONFIG+=$'\n'"Q_USE_PROVIDERNET_FOR_PUBLIC=True"
export DEVSTACK_LOCAL_CONFIG+=$'\n'"PHYSICAL_NETWORK=public"

if [[ "${OVN_OPTS}" == *"latest-release"* ]] ; then
export DEVSTACK_LOCAL_CONFIG+=$'\n'"OVN_BRANCH=branch-2.12"
elif [[ "${OVN_OPTS}" == *"master"* ]] ; then
export DEVSTACK_LOCAL_CONFIG+=$'\n'"OVN_BRANCH=master"
else
echo "No ovs branch specified, using the default from the devstack plugin"
fi

# Enable controller to host gateway routers
export DEVSTACK_LOCAL_CONFIG+=$'\n'"ENABLE_CHASSIS_AS_GW=True"

if [[ "$DEVSTACK_GATE_TOPOLOGY" == "multinode" ]] ; then
# NOTE(rtheis): Multinode does not require creating an OVN L3 public network.
export DEVSTACK_LOCAL_CONFIG+=$'\n'"OVN_L3_CREATE_PUBLIC_NETWORK=False"

# NOTE(rtheis): Configure the enabled services on the compute node.
export DEVSTACK_SUBNODE_CONFIG+=$'\n'"ENABLED_SERVICES=n-cpu,dstat,c-vol,c-bak,ovn-controller"

# NOTE(rtheis): Configure OVN on the compute node.
export DEVSTACK_SUBNODE_CONFIG+=$'\n'"OVN_SB_REMOTE=tcp:\$SERVICE_HOST:6642"
export DEVSTACK_SUBNODE_CONFIG+=$'\n'"OVN_NB_REMOTE=tcp:\$SERVICE_HOST:6641"

# NOTE(rtheis): Since we are overriding the enabled services, we must
# also configure the database and rabbit services on the compute node.
export DEVSTACK_SUBNODE_CONFIG+=$'\n'"DATABASE_HOST=\$SERVICE_HOST"
export DEVSTACK_SUBNODE_CONFIG+=$'\n'"DATABASE_TYPE=mysql"
export DEVSTACK_SUBNODE_CONFIG+=$'\n'"RABBIT_HOST=\$SERVICE_HOST"
else
export DEVSTACK_LOCAL_CONFIG+=$'\n'"OVN_L3_CREATE_PUBLIC_NETWORK=True"
fi

# Begin list of exclusions.
r="^(?!.*"

# exclude the slow tag (part of the default for 'full')
r="$r(?:.*\[.*\bslow\b.*\])"

# exclude things that just aren't enabled with OVN
r="$r|(?:tempest\.api\.network\.admin\.test_quotas\.QuotasTest\.test_lbaas_quotas.*)"
r="$r|(?:tempest\.api\.network\.test_load_balancer.*)"
r="$r|(?:tempest\.scenario\.test_load_balancer.*)"
r="$r|(?:tempest\.api\.network\.admin\.test_load_balancer.*)"
r="$r|(?:tempest\.api\.network\.admin\.test_lbaas.*)"
r="$r|(?:tempest\.api\.network\.test_fwaas_extensions.*)"
r="$r|(?:tempest\.api\.network\.test_metering_extensions.*)"
r="$r|(?:tempest\.thirdparty\.boto\.test_s3.*)"

# TODO(dalvarez): remove this exclusion when https://bugs.launchpad.net/tempest/+bug/1728886 is fixed
r="$r|(?:tempest\.scenario\.test_network_basic_ops\.TestNetworkBasicOps\.test_port_security_macspoofing_port)"

# exclude some unrelated stuff to make networking-ovn targeted runs go faster
r="$r|(?:tempest\.api\.identity*)"
r="$r|(?:tempest\.api\.image*)"
r="$r|(?:tempest\.api\.volume*)"
r="$r|(?:tempest\.api\.compute\.images*)"
r="$r|(?:tempest\.api\.compute\.keypairs*)"
r="$r|(?:tempest\.api\.compute\.certificates*)"
r="$r|(?:tempest\.api\.compute\.flavors*)"
r="$r|(?:tempest\.api\.compute\.test_quotas*)"
r="$r|(?:tempest\.api\.compute\.test_versions*)"
r="$r|(?:tempest\.api\.compute\.volumes*)"
r="$r|(?:tempest\.api\.compute\.admin\.test_flavor*)"
r="$r|(?:tempest\.api\.compute\.admin\.test_volume*)"
r="$r|(?:tempest\.api\.compute\.admin\.test_hypervisor*)"
r="$r|(?:tempest\.api\.compute\.admin\.test_aggregate*)"
r="$r|(?:tempest\.api\.compute\.admin\.test_quota*)"

r="$r|(?:tempest\.scenario\.test_volume*)"

# End list of exclusions.
r="$r)"

r="$r((^neutron_tempest_plugin\.api)|(^neutron_tempest_plugin\.scenario)|(tempest\.(api|scenario|thirdparty))).*$"

export DEVSTACK_GATE_TEMPEST_REGEX="$r"

+ 0
- 1
devstack/files/debs/networking_ovn View File

@@ -1 +0,0 @@
python3-dev

+ 0
- 1
devstack/files/rpms/networking_ovn View File

@@ -1 +0,0 @@
python3-devel

+ 0
- 610
devstack/lib/networking-ovn View File

@@ -1,610 +0,0 @@
#!/bin/bash

# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.

# devstack/plugin.sh
# Functions to control the configuration and operation of the OVN service

# Dependencies:
#
# ``functions`` file
# ``DEST`` must be defined
# ``STACK_USER`` must be defined

# ``stack.sh`` calls the entry points in this order:
#
# - install_ovn
# - configure_ovn
# - configure_ovn_plugin
# - init_ovn
# - start_ovn
# - stop_ovn
# - cleanup_ovn

# Save trace setting
_XTRACE_NETWORKING_OVN=$(set +o | grep xtrace)
set +o xtrace

# Libraries that could be installed from source

GITREPO["ovsdbapp"]=${OVSDBAPP_REPO:-${GIT_BASE}/openstack/ovsdbapp.git}
GITBRANCH["ovsdbapp"]=${OVSDBAPP_BRANCH:-master}
GITDIR["ovsdbapp"]=$DEST/ovsdbapp

# Defaults
# --------

# The project directory
NETWORKING_OVN_DIR=$DEST/networking-ovn

# How to connect to ovsdb-server hosting the OVN SB database.
OVN_SB_REMOTE=${OVN_SB_REMOTE:-tcp:$SERVICE_HOST:6642}

# How to connect to ovsdb-server hosting the OVN NB database
OVN_NB_REMOTE=${OVN_NB_REMOTE:-tcp:$SERVICE_HOST:6641}

# A UUID to uniquely identify this system. If one is not specified, a random
# one will be generated. A randomly generated UUID will be saved in a file
# 'ovn-uuid' so that the same one will be re-used if you re-run DevStack.
OVN_UUID=${OVN_UUID:-}

# Whether or not to build the openvswitch kernel module from ovs. This is required
# unless the distro kernel includes ovs+conntrack support.
OVN_BUILD_MODULES=$(trueorfalse False OVN_BUILD_MODULES)

# Whether or not to install the ovs python module from ovs source. This can be
# used to test and validate new ovs python features. This should only be used
# for development purposes since the ovs python version is controlled by OpenStack
# requirements.
OVN_INSTALL_OVS_PYTHON_MODULE=$(trueorfalse False OVN_INSTALL_OVS_PYTHON_MODULE)

# GENEVE overlay protocol overhead. Defaults to 38 bytes plus the IP version
# overhead (20 bytes for IPv4 (default) or 40 bytes for IPv6) which is determined
# based on the ML2 overlay_ip_version option. The ML2 framework will use this to
# configure the MTU DHCP option.
OVN_GENEVE_OVERHEAD=${OVN_GENEVE_OVERHEAD:-38}

# This sets whether to create a public network and bridge.
# If set to True, a public network and subnet(s) will be created, and a router
# will be created to route the default private network to the public one.
OVN_L3_CREATE_PUBLIC_NETWORK=$(trueorfalse False OVN_L3_CREATE_PUBLIC_NETWORK)

# ml2/config for neutron_sync_mode
OVN_NEUTRON_SYNC_MODE=${OVN_NEUTRON_SYNC_MODE:-log}

# The type of OVN L3 Scheduler to use. The OVN L3 Scheduler determines the
# hypervisor/chassis where a routers gateway should be hosted in OVN. The
# default OVN L3 scheduler is leastloaded
OVN_L3_SCHEDULER=${OVN_L3_SCHEDULER:-leastloaded}

# The log level of the OVN databases (north and south)
OVN_DBS_LOG_LEVEL=${OVN_DBS_LOG_LEVEL:-info}

# Configured DNS servers to be used with internal_dns extension, only
# if the subnet DNS is not configured.
OVN_DNS_SERVERS=${OVN_DNS_SERVERS:-8.8.8.8}

# Neutron directory
NEUTRON_DIR=$DEST/neutron

OVN_META_CONF=$NEUTRON_CONF_DIR/networking_ovn_metadata_agent.ini

OVS_PREFIX=/usr/local
OVS_SBINDIR=$OVS_PREFIX/sbin
OVS_BINDIR=$OVS_PREFIX/bin
OVS_RUNDIR=$OVS_PREFIX/var/run/openvswitch
OVS_SHAREDIR=$OVS_PREFIX/share/openvswitch
OVS_SCRIPTDIR=$OVS_SHAREDIR/scripts
OVS_DATADIR=$DATA_DIR/ovs

OVN_DATADIR=$DATA_DIR/ovn
OVN_SHAREDIR=$OVS_PREFIX/share/ovn
OVN_SCRIPTDIR=$OVN_SHAREDIR/scripts
OVN_RUNDIR=$OVS_PREFIX/var/run/ovn

NETWORKING_OVN_BIN_DIR=$(get_python_exec_prefix)
NETWORKING_OVN_METADATA_BINARY="networking-ovn-metadata-agent"

# Utility Functions
# -----------------

# There are some ovs functions OVN depends on that must be sourced from
# the ovs neutron plugins. After doing this, the OVN overrides must be
# re-sourced.
source $TOP_DIR/lib/neutron_plugins/ovs_base
source $TOP_DIR/lib/neutron_plugins/openvswitch_agent
source $NETWORKING_OVN_DIR/devstack/override-defaults
source $NETWORKING_OVN_DIR/devstack/network_utils.sh
source $NETWORKING_OVN_DIR/devstack/lib/ovn

# NOTE(rtheis): Function copied from DevStack _neutron_ovs_base_setup_bridge
# and _neutron_ovs_base_add_bridge with the call to neutron-ovs-cleanup
# removed. The call is not relevant for OVN, as it is specific to the use
# of Neutron's OVS agent and hangs when running stack.sh because
# neutron-ovs-cleanup uses the OVSDB native interface.
function ovn_base_setup_bridge {
local bridge=$1
local addbr_cmd="ovs-vsctl --no-wait -- --may-exist add-br $bridge"

if [ "$OVS_DATAPATH_TYPE" != "system" ] ; then
addbr_cmd="$addbr_cmd -- set Bridge $bridge datapath_type=${OVS_DATAPATH_TYPE}"
fi

$addbr_cmd
ovs-vsctl --no-wait br-set-external-id $bridge bridge-id $bridge
}

function _start_process {
$SYSTEMCTL daemon-reload
$SYSTEMCTL enable $1
$SYSTEMCTL restart $1
}

function _run_process {
local service=$1
local cmd="$2"
local stop_cmd="$3"
local group=$4
local user=${5:-$STACK_USER}

local systemd_service="devstack@$service.service"
local unit_file="$SYSTEMD_DIR/$systemd_service"
local environment="OVN_RUNDIR=$OVS_RUNDIR OVN_DBDIR=$OVN_DATADIR OVN_LOGDIR=$LOGDIR OVS_RUNDIR=$OVS_RUNDIR OVS_DBDIR=$OVS_DATADIR OVS_LOGDIR=$LOGDIR"

echo "Starting $service executed command": $cmd

write_user_unit_file $systemd_service "$cmd" "$group" "$user"
iniset -sudo $unit_file "Service" "Type" "forking"
iniset -sudo $unit_file "Service" "RemainAfterExit" "yes"
iniset -sudo $unit_file "Service" "KillMode" "mixed"
iniset -sudo $unit_file "Service" "LimitNOFILE" "65536"
iniset -sudo $unit_file "Service" "Environment" "$environment"
if [ -n "$stop_cmd" ]; then
iniset -sudo $unit_file "Service" "ExecStop" "$stop_cmd"
fi

_start_process $systemd_service

local testcmd="test -e $OVS_RUNDIR/$service.pid"
test_with_retry "$testcmd" "$service did not start" $SERVICE_TIMEOUT 1
sudo ovs-appctl -t $service vlog/set console:off syslog:info file:info
}

# Entry Points
# ------------

function _cleanup {
local path=${1:-$DEST/$OVN_REPO_NAME}
pushd $path
cd $path
sudo make uninstall
sudo make distclean
popd
}

# cleanup_ovn() - Remove residual data files, anything left over from previous
# runs that a clean run would need to clean up
function cleanup_ovn {
local ovn_path=$DEST/$OVN_REPO_NAME
local ovs_path=$DEST/$OVS_REPO_NAME

if [ -d $ovn_path ]; then
_cleanup $ovn_path
fi

if [ -d $ovs_path ]; then
_cleanup $ovs_path
fi

sudo rm -f $OVN_RUNDIR
}

# configure_ovn() - Set config files, create data dirs, etc
function configure_ovn {
echo "Configuring OVN"

if [ -z "$OVN_UUID" ] ; then
if [ -f ./ovn-uuid ] ; then
OVN_UUID=$(cat ovn-uuid)
else
OVN_UUID=$(uuidgen)
echo $OVN_UUID > ovn-uuid
fi
fi

# Metadata
if is_service_enabled networking-ovn-metadata-agent && is_service_enabled ovn-controller; then
sudo install -d -o $STACK_USER $NEUTRON_CONF_DIR

configure_neutron_rootwrap

mkdir -p $NETWORKING_OVN_DIR/etc/neutron/plugins/ml2
(cd $NETWORKING_OVN_DIR && exec ./tools/generate_config_file_samples.sh)

cp $NETWORKING_OVN_DIR/etc/networking_ovn_metadata_agent.ini.sample $OVN_META_CONF
configure_root_helper_options $OVN_META_CONF

iniset $OVN_META_CONF DEFAULT debug $ENABLE_DEBUG_LOG_LEVEL
iniset $OVN_META_CONF DEFAULT nova_metadata_host $SERVICE_HOST
iniset $OVN_META_CONF DEFAULT metadata_workers $API_WORKERS
iniset $OVN_META_CONF DEFAULT state_path $NEUTRON_STATE_PATH
iniset $OVN_META_CONF ovs ovsdb_connection unix:$OVS_RUNDIR/db.sock
iniset $OVN_META_CONF ovn ovn_sb_connection $OVN_SB_REMOTE
fi
}

function configure_ovn_plugin {
echo "Configuring Neutron for OVN"

if is_service_enabled q-svc ; then
# NOTE(arosen) needed for tempest
export NETWORK_API_EXTENSIONS=$($PYTHON -c \
'from networking_ovn.common import extensions ;\
print(",".join(extensions.ML2_SUPPORTED_API_EXTENSIONS))')
export NETWORK_API_EXTENSIONS=$NETWORK_API_EXTENSIONS,$($PYTHON -c \
'from networking_ovn.common import extensions ;\
print(",".join(extensions.ML2_SUPPORTED_API_EXTENSIONS_OVN_L3))')
populate_ml2_config /$Q_PLUGIN_CONF_FILE ml2_type_geneve max_header_size=$OVN_GENEVE_OVERHEAD
populate_ml2_config /$Q_PLUGIN_CONF_FILE ovn ovn_nb_connection="$OVN_NB_REMOTE"
populate_ml2_config /$Q_PLUGIN_CONF_FILE ovn ovn_sb_connection="$OVN_SB_REMOTE"
populate_ml2_config /$Q_PLUGIN_CONF_FILE ovn neutron_sync_mode="$OVN_NEUTRON_SYNC_MODE"
populate_ml2_config /$Q_PLUGIN_CONF_FILE ovn ovn_l3_scheduler="$OVN_L3_SCHEDULER"
populate_ml2_config /$Q_PLUGIN_CONF_FILE securitygroup enable_security_group="$Q_USE_SECGROUP"
inicomment /$Q_PLUGIN_CONF_FILE securitygroup firewall_driver

if is_service_enabled networking-ovn-metadata-agent; then
populate_ml2_config /$Q_PLUGIN_CONF_FILE ovn ovn_metadata_enabled=True
else
populate_ml2_config /$Q_PLUGIN_CONF_FILE ovn ovn_metadata_enabled=False
fi

if is_service_enabled q-dns neutron-dns ; then
iniset $NEUTRON_CONF DEFAULT dns_domain openstackgate.local
populate_ml2_config /$Q_PLUGIN_CONF_FILE ovn dns_servers="$OVN_DNS_SERVERS"
fi
fi

if is_service_enabled q-dhcp ; then
iniset $NEUTRON_CONF DEFAULT dhcp_agent_notification True
else
iniset $NEUTRON_CONF DEFAULT dhcp_agent_notification False
fi

if is_service_enabled q-l3 ; then
die $LINENO "The q-l3 service must be disabled with OVN."
fi

# NOTE(rtheis): OVN currently lacks support for metadata so enabling
# config drive is required to provide metadata to instances.
if is_service_enabled n-api-meta ; then
if is_service_enabled networking-ovn-metadata-agent ; then
iniset $NOVA_CONF neutron service_metadata_proxy True
else
iniset $NOVA_CONF DEFAULT force_config_drive True
fi
fi
}

# init_ovn() - Initialize databases, etc.
function init_ovn {
# clean up from previous (possibly aborted) runs
# create required data files

# Assumption: this is a dedicated test system and there is nothing important
# in the ovn, ovn-nb, or ovs databases. We're going to trash them and
# create new ones on each devstack run.

mkdir -p $OVN_DATADIR
mkdir -p $OVS_DATADIR

rm -f $OVS_DATADIR/*.db
rm -f $OVS_DATADIR/.*.db.~lock~
rm -f $OVN_DATADIR/*.db
rm -f $OVN_DATADIR/.*.db.~lock~
}

# install_ovn() - Collect source and prepare
function install_ovn {
echo "Installing OVN and dependent packages"

# If OVS is already installed, remove it, because we're about to re-install
# it from source.
for package in openvswitch openvswitch-switch openvswitch-common; do
if is_package_installed $package ; then
uninstall_package $package
fi
done

if ! is_neutron_enabled ; then
# NOTE(rtheis): networking-ovn depends on neutron, so ensure it at
# least gets installed and its configuration directory exists (which
# is needed by the multinode job).
install_neutron
sudo install -d -o $STACK_USER $NEUTRON_CONF_DIR
fi

# Install tox, used to generate the config (see devstack/override-defaults)
pip_install tox
source $NEUTRON_DIR/devstack/lib/ovs
remove_ovs_packages
sudo rm -f $OVS_RUNDIR/*

if use_new_ovn_repository; then
compile_ovn $OVN_BUILD_MODULES
else
compile_ovs $OVN_BUILD_MODULES
fi

sudo mkdir -p $OVS_RUNDIR
sudo chown $(whoami) $OVS_RUNDIR
sudo mkdir -p $OVS_PREFIX/var/log/openvswitch
sudo chown $(whoami) $OVS_PREFIX/var/log/openvswitch
sudo mkdir -p $OVS_PREFIX/var/log/ovn
sudo chown $(whoami) $OVS_PREFIX/var/log/ovn

# Archive log files and create new
local log_archive_dir=$LOGDIR/archive
mkdir -p $log_archive_dir
for logfile in ovs-vswitchd.log ovn-northd.log ovn-controller.log ovn-controller-vtep.log ovs-vtep.log ovsdb-server.log ovsdb-server-nb.log ovsdb-server-sb.log; do
if [ -f "$LOGDIR/$logfile" ] ; then
mv "$LOGDIR/$logfile" "$log_archive_dir/$logfile.${CURRENT_LOG_TIME}"
fi
done

# Install ovsdbapp from source if requested
if use_library_from_git "ovsdbapp"; then
git_clone_by_name "ovsdbapp"
setup_dev_lib "ovsdbapp"
fi

setup_develop $DEST/networking-ovn

# Install ovs python module from ovs source.
if [[ "$OVN_INSTALL_OVS_PYTHON_MODULE" == "True" ]]; then
sudo pip uninstall -y ovs
# Clone the OVS repository if it's not yet present
clone_repository $OVS_REPO $OVS_BRANCH
sudo pip install -e $DEST/$OVS_REPO_NAME/python
fi
}

function start_ovs {
echo "Starting OVS"
if is_service_enabled ovn-controller || is_service_enabled ovn-controller-vtep ; then
# ovsdb-server and ovs-vswitchd are used privately in OVN as openvswitch service names.
enable_service ovsdb-server
enable_service ovs-vswitchd

if [ ! -f $OVS_DATADIR/conf.db ]; then
ovsdb-tool create $OVS_DATADIR/conf.db $OVS_SHAREDIR/vswitch.ovsschema
fi

if is_service_enabled ovn-controller-vtep; then
if [ ! -f $OVS_DATADIR/vtep.db ]; then
ovsdb-tool create $OVS_DATADIR/vtep.db $OVS_SHAREDIR/vtep.ovsschema
fi
fi

local dbcmd="$OVS_SBINDIR/ovsdb-server --remote=punix:$OVS_RUNDIR/db.sock --remote=ptcp:6640:127.0.0.1 --pidfile --detach --log-file"
dbcmd+=" --remote=db:Open_vSwitch,Open_vSwitch,manager_options"
if is_service_enabled ovn-controller-vtep; then
dbcmd+=" --remote=db:hardware_vtep,Global,managers $OVS_DATADIR/vtep.db"
fi
dbcmd+=" $OVS_DATADIR/conf.db"
_run_process ovsdb-server "$dbcmd"

echo "Configuring OVSDB"
ovs-vsctl --no-wait set open_vswitch . system-type="devstack"
ovs-vsctl --no-wait set open_vswitch . external-ids:system-id="$OVN_UUID"
ovs-vsctl --no-wait set open_vswitch . external-ids:ovn-remote="$OVN_SB_REMOTE"
ovs-vsctl --no-wait set open_vswitch . external-ids:ovn-bridge="br-int"
ovs-vsctl --no-wait set open_vswitch . external-ids:ovn-encap-type="geneve,vxlan"
ovs-vsctl --no-wait set open_vswitch . external-ids:ovn-encap-ip="$HOST_IP"
# Select this chassis to host gateway routers
if [[ "$ENABLE_CHASSIS_AS_GW" == "True" ]]; then
ovs-vsctl --no-wait set open_vswitch . external-ids:ovn-cms-options="enable-chassis-as-gw"
fi

ovn_base_setup_bridge br-int
ovs-vsctl --no-wait set bridge br-int fail-mode=secure other-config:disable-in-band=true

local ovscmd="$OVS_SBINDIR/ovs-vswitchd --log-file --pidfile --detach"
_run_process ovs-vswitchd "$ovscmd" "" "$STACK_USER" "root"

if is_provider_network || [[ $Q_USE_PROVIDERNET_FOR_PUBLIC == "True" ]]; then
ovn_base_setup_bridge $OVS_PHYSICAL_BRIDGE
ovs-vsctl set open . external-ids:ovn-bridge-mappings=${PHYSICAL_NETWORK}:${OVS_PHYSICAL_BRIDGE}
fi

if is_service_enabled ovn-controller-vtep ; then
ovn_base_setup_bridge br-v
vtep-ctl add-ps br-v
vtep-ctl set Physical_Switch br-v tunnel_ips=$HOST_IP

enable_service ovs-vtep
local vtepcmd="$OVS_SCRIPTDIR/ovs-vtep --log-file --pidfile --detach br-v"
_run_process ovs-vtep "$vtepcmd" "" "$STACK_USER" "root"

vtep-ctl set-manager tcp:$HOST_IP:6640
fi
fi

cd $_pwd
}

# start_ovn() - Start running processes, including screen
function start_ovn {
echo "Starting OVN"

local SCRIPTDIR=$OVN_SCRIPTDIR
if ! use_new_ovn_repository; then
SCRIPTDIR=$OVS_SCRIPTDIR
fi

if is_service_enabled ovn-northd ; then
local cmd="/bin/bash $SCRIPTDIR/ovn-ctl --no-monitor start_northd"
local stop_cmd="/bin/bash $SCRIPTDIR/ovn-ctl stop_northd"

_run_process ovn-northd "$cmd" "$stop_cmd"
ovn-nbctl --db=unix:$OVS_RUNDIR/ovnnb_db.sock set-connection ptcp:6641:0.0.0.0 -- set connection . inactivity_probe=60000
ovn-sbctl --db=unix:$OVS_RUNDIR/ovnsb_db.sock set-connection ptcp:6642:0.0.0.0 -- set connection . inactivity_probe=60000
sudo ovs-appctl -t $OVS_RUNDIR/ovnnb_db.ctl vlog/set console:off syslog:$OVN_DBS_LOG_LEVEL file:$OVN_DBS_LOG_LEVEL
sudo ovs-appctl -t $OVS_RUNDIR/ovnsb_db.ctl vlog/set console:off syslog:$OVN_DBS_LOG_LEVEL file:$OVN_DBS_LOG_LEVEL
fi

if is_service_enabled ovn-controller ; then
local cmd="/bin/bash $SCRIPTDIR/ovn-ctl --no-monitor start_controller"
local stop_cmd="/bin/bash $SCRIPTDIR/ovn-ctl stop_controller"

_run_process ovn-controller "$cmd" "$stop_cmd" "$STACK_USER" "root"
fi

if is_service_enabled ovn-controller-vtep ; then
local cmd="$OVS_BINDIR/ovn-controller-vtep --log-file --pidfile --detach --ovnsb-db=$OVN_SB_REMOTE"

_run_process ovn-controller-vtep "$cmd" "" "$STACK_USER" "root"
fi

if is_service_enabled networking-ovn-metadata-agent; then
run_process networking-ovn-metadata-agent "$NETWORKING_OVN_BIN_DIR/$NETWORKING_OVN_METADATA_BINARY --config-file $OVN_META_CONF"
# Format logging
setup_logging $OVN_META_CONF
fi

if is_service_enabled br-ex-tcpdump ; then
# tcpdump monitor on br-ex for ARP, reverse ARP and ICMP v4 / v6 packets
sudo ip link set dev $PUBLIC_BRIDGE up
run_process br-ex-tcpdump "/usr/sbin/tcpdump -i $PUBLIC_BRIDGE arp or rarp or icmp or icmp6 -enlX" $STACK_USER root
fi

if is_service_enabled br-int-flows ; then
run_process br-int-flows "/bin/sh -c \"set +e; while true; do echo ovs-ofctl dump-flows br-int; ovs-ofctl dump-flows br-int ; sleep 30; done; \"" $STACK_USER root
fi

# NOTE(lucasagomes): To keep things simpler, let's reuse the same
# RUNDIR for both OVS and OVN. This way we avoid having to specify the
# --db option in the ovn-{n,s}bctl commands while playing with DevStack
if use_new_ovn_repository; then
sudo ln -s $OVS_RUNDIR $OVN_RUNDIR
fi
}

# stop_ovn() - Stop running processes (non-screen)
function stop_ovn {
if is_service_enabled networking-ovn-metadata-agent; then
sudo pkill -9 -f haproxy || :
stop_process networking-ovn-metadata-agent
fi
if is_service_enabled ovn-controller-vtep ; then
stop_process ovn-controller-vtep
fi
if is_service_enabled ovn-controller ; then
stop_process ovn-controller
fi
if is_service_enabled ovn-northd ; then
stop_process ovn-northd
fi
if is_service_enabled ovs-vtep ; then
stop_process ovs-vtep
fi

stop_process ovs-vswitchd
stop_process ovsdb-server
}

function start_ovn_services {
_start_process "devstack@ovsdb-server.service"
_start_process "devstack@ovs-vswitchd.service"

if is_service_enabled ovs-vtep ; then
_start_process "devstack@ovs-vtep.service"
fi
if is_service_enabled ovn-northd ; then
_start_process "devstack@ovn-northd.service"
fi
if is_service_enabled ovn-controller ; then
_start_process "devstack@ovn-controller.service"
fi
if is_service_enabled ovn-controller-vtep ; then
_start_process "devstack@ovn-controller-vtep.service"
fi
if is_service_enabled networking-ovn-metadata-agent; then
_start_process "devstack@networking-ovn-metadata-agent.service"
fi
}

function is_kernel_module_loaded {
if lsmod | grep $1 >& /dev/null; then
return 0
else
return 1
fi
}

# stop_ovs_dp() - Stop OVS datapath
function stop_ovs_dp {
sudo ovs-dpctl dump-dps | sudo xargs -n1 ovs-dpctl del-dp
is_kernel_module_loaded vport_geneve && sudo rmmod vport_geneve
is_kernel_module_loaded vport_vxlan && sudo rmmod vport_vxlan
is_kernel_module_loaded openvswitch && sudo rmmod openvswitch
}

function disable_libvirt_apparmor {
if ! sudo aa-status --enabled ; then
return 0
fi
# NOTE(arosen): This is used as a work around to allow newer versions
# of libvirt to work with ovs configured ports. See LP#1466631.
# requires the apparmor-utils
install_package apparmor-utils
# disables apparmor for libvirtd
sudo aa-complain /etc/apparmor.d/usr.sbin.libvirtd
}

function create_public_bridge {
# Create the public bridge that OVN will use
# This logic is based on the devstack neutron-legacy _neutron_configure_router_v4 and _v6
local ext_gw_ifc
ext_gw_ifc=$(get_ext_gw_interface)

ovs-vsctl --may-exist add-br $ext_gw_ifc -- set bridge $ext_gw_ifc protocols=OpenFlow13
ovs-vsctl set open . external-ids:ovn-bridge-mappings=$PHYSICAL_NETWORK:$ext_gw_ifc
if [ -n "$FLOATING_RANGE" ]; then
local cidr_len=${FLOATING_RANGE#*/}
sudo ip addr add $PUBLIC_NETWORK_GATEWAY/$cidr_len dev $ext_gw_ifc
fi

# Ensure IPv6 RAs are accepted on the interface with the default route.
# This is needed for neutron-based devstack clouds to work in
# IPv6-only clouds in the gate. Please do not remove this without
# talking to folks in Infra. This fix is based on a devstack fix for
# neutron L3 agent: https://review.openstack.org/#/c/359490/.
default_route_dev=$(ip route | grep ^default | awk '{print $5}')
sudo sysctl -w net.ipv6.conf.$default_route_dev.accept_ra=2

sudo sysctl -w net.ipv6.conf.all.forwarding=1
if [ -n "$IPV6_PUBLIC_RANGE" ]; then
local ipv6_cidr_len=${IPV6_PUBLIC_RANGE#*/}
sudo ip -6 addr add $IPV6_PUBLIC_NETWORK_GATEWAY/$ipv6_cidr_len dev $ext_gw_ifc
# NOTE(numans): Commenting the below code for now as this is breaking
# the CI after xenial upgrade.
# https://bugs.launchpad.net/networking-ovn/+bug/1648670
# sudo ip -6 route replace $FIXED_RANGE_V6 via $IPV6_PUBLIC_NETWORK_GATEWAY dev $ext_gw_ifc
fi

sudo ip link set $ext_gw_ifc up
}


# Restore xtrace
$_XTRACE_NETWORKING_OVN

+ 0
- 22
devstack/lib/octavia View File

@@ -1,22 +0,0 @@
#!/usr/bin/env bash

# Save trace setting
XTRACE=$(set +o | grep xtrace)
set +o xtrace

if is_plugin_enabled octavia; then
function octavia_create_network_interface_device {
INTERFACE=$1
MGMT_PORT_ID=$2
MGMT_PORT_MAC=$3
openstack subnet set --gateway none lb-mgmt-subnet
sudo ovs-vsctl -- --may-exist add-port ${OVS_BRIDGE:-br-int} o-hm0 -- set Interface o-hm0 type=internal -- set Interface o-hm0 external-ids:iface-status=active -- set Interface o-hm0 external-ids:attached-mac=$MGMT_PORT_MAC -- set Interface o-hm0 external-ids:iface-id=$MGMT_PORT_ID -- set Interface o-hm0 external-ids:skip_cleanup=true
}

function octavia_delete_network_interface_device {
: # Do nothing
}
fi

# Restore xtrace
$XTRACE

+ 0
- 180
devstack/lib/ovn View File

@@ -1,180 +0,0 @@
#!/bin/bash
#
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
#

# Set variables for building OVN from source
OVN_REPO=${OVN_REPO:-https://github.com/ovn-org/ovn.git}
OVN_REPO_NAME=$(basename ${OVN_REPO} | cut -f1 -d'.')
OVN_BRANCH=${OVN_BRANCH:-master}

# Set variables for building OVS from source
OVS_REPO=${OVS_REPO:-https://github.com/openvswitch/ovs.git}
OVS_REPO_NAME=$(basename ${OVS_REPO} | cut -f1 -d'.')
OVS_BRANCH=$OVN_BRANCH


function use_new_ovn_repository {
# IF OVN_BRANCH is "master" or branch-2.13 (or higher), use the new
# OVN repository
if [ "$OVN_BRANCH" == "master" ] || \
[ $(echo $OVN_BRANCH | sed -e 's/^branch-\([0-9]*\)\.//') -ge 13 ]; then
return 0
else
return 1
fi
}


function clone_repository {
local repo=$1
local branch=$2
local repo_name=$(basename ${repo} | cut -f1 -d'.')

REPO_DIR=$DEST/$repo_name

if [ ! -d $REPO_DIR ] ; then
git_timed clone $repo $REPO_DIR
pushd $REPO_DIR
git checkout $branch
popd
else
# Even though the directory already exists, call git_clone to update it
# if needed based on the RECLONE option
git_clone $repo $REPO_DIR $branch
fi
}

# _prepare_for_ovs_compilation() - Fetch the ovs git repository
# and install packages needed for the compilation.
function _prepare_for_ovs_compilation {
local build_modules=$1
clone_repository $OVS_REPO $OVS_BRANCH

if [[ "$build_modules" == "False" ]]; then
return</