If the required extensions are missing, we currently log an error
that is going to be practically ignored. That said, the unfulfilled
requirement will most definitely going to lead to other failures,
so we might as well fail fast.
This patch also cleans up some <barf>dns-integration nonsense</barf>
within the ML2 framework: the extension must not be declared statically
as it's being loaded by the extension manager, and this fixes the lousy
unit tests we have to live with. As for the db base plugin, some cleanup
is still overdue, but it will have to be taken care of in a follow-up
patch.
Closes-bug: #1538623
Change-Id: Id50eeb52c5d209170042b48821a29af3421c2f5c
This command should be used by operators and deployment tools to
determine whether full neutron-server shutdown is needed for database
upgrade.
The change also makes neutron-db-manage tool to return the cumulative
result of commands being issued (in most cases it will still be 0 only,
since our command handlers implicitly return None).
DocImpact: Update doc to add new command 'has_offline_migrations' to
'neutron-db-manage' tool. The command determines whether full
neutron-server shutdown is needed for database upgrade.
Closes-Bug: #1519118
Change-Id: I7c5a4882ad4f80459ebe69c9a9c43cc60ce50200
Co-Authored-By: Martin Hickey <martin.hickey@ie.ibm.com>
An interface with an external DNS service is defined for Neutron. A reference
implementation is also included, based on Designate. The interface and the
driver will enable users to publish in the external DNS service the dns_name
and dns_domain attributes associated with floating ips, ports and networks. As
a consequence, the floating ips and networks api is extended to manage dns_name
and dns_domain attributes. The dns_name attribute was added to ports in a
preceding commit
DocImpact: Introduce config option external_dns_driver to specify a driver
for external dns integration. For more info, see
doc/source/devref/external_dns_integration.rst
APIImpact
Implements: blueprint external-dns-resolution
Change-Id: Ic298ad2558410ab9a614f22e1757d1fc8b22c482
Methods _create_ha_network, add_ha_port don't have wrapping
transaction in them, so they are prone to race conditions.
This commit adds a transaction to them. To avoid problem with
rolling back outmost transaction during exception handling,
internal methods have been wrapped in nested transaction.
Nested transaction is required in places like this:
def create():
create_something()
try:
_do_other_thing()
except Exception:
with excutils.save_and_reraise_exception():
delete_something()
def _do_other_thing():
with context.session.begin(subtransactions=True):
....
When exception is raised in _do_other_thing it
is caught in except block, but the object cannot be deleted in
except section because internal transaction has been rolled back.
A new method safe_creation and has been added
that provides a common way of handling such situations.
Closes-bug: #1501686
Change-Id: I952f6f7f8684743aa7f829bd92b1dc41b2c6aecf
The OPNFV project [1] is a reference implementation of the
ETSI NFV architecture built on open source components.
OpenStack, and Neutron in particular, are key elements of
this story, and many requirements and issues are driven and
submitted by OPNFV folks that work in both communities.
This tag makes sure that we can keep all of them together for
tracking purposes.
[1] http://superuser.openstack.org/articles/openstack-and-opnfv-strengthen-collaboration-for-telcos
Change-Id: Ie1675ef6f177558f579097fe035494b9380232d0
We switched to constrained jobs a while back, but these links were
showing the non constrained ones, making these graphs useless.
This patch updates them to reflect the jobs that are currently
running, however the docs job is left for later as right now
switching would make graphite fail with:
'TypeError: reduce() of empty sequence with no initial value'
I suspect that's because the job has never failed so far.
Change-Id: I60cab40f3c12099d8437616d8301aecd858ef54c
os.popen() is deprecated since version 2.6. Resolved with use of
subprocess module.
Change-Id: I2ff32c4dc37c543696125ac755dc4adb69ddacdf
Partial-Bug: #1529836
The L3 agent needs to know the address scope of the fixed ip of each
floating ip because floating ips are a way to cross scope boundaries.
Without the scope information, there could be ambiguity and no way to
know which scope to send it to.
[1] https://review.openstack.org/#/c/189741/
Change-Id: Id9f8c12954a6efbf4d9b99c011652eefbe5f5145
Partially-Implements: blueprint address-scopes
This patch adds unit tests to ML2 and L3 that ensure that the
number of DB calls during list operations for ports, networks,
subnets, routers, and floating IPs remains constant regardless
of the number of ports.
These will prevent changes from slipping in that result in
a separate DB query for each object in a list operation
(for changes to the extensions used by ML2 and the DVR plugin).
Related-Bug: #1525295
Related-Bug: #1513782
Related-Bug: #1525423
Related-Bug: #1525740
Related-Bug: #1526644
Change-Id: I1958fc7c318bbf73238a3ad5be133fa7800c8290
There have been a number of regressions caused by our inability
to thoroughly review relatiohships' loading strategies. We should
at least make an attempt to remind ourselves, and since I am guilty
as charged, this patch is my attempt to redemption.
Change-Id: I879cfceaa51386e9d6c683e7e02487df92b7e290
The rationale is that we would have a single tag to track all
bugs that are about admin and user ease of use, logging quality,
and debuggability.
Change-Id: Ie42e08c924c9e742bdc6d9f4b68bdfbd1a622ba4
Below changes are done as part of this patch.
* Mention about ONOS l3 support.
* Proposing Mr. Albert Dongfeng as a lieutenant for networking-onos.
Change-Id: I87827b08ed868f68cbd49c1fa7b91352d3c46605
The L3 agent needs to know the address scope of each port of each
router it sets up in order to enforce isolation between scopes.
This commit adds a devref for the address scopes and subnet pools
features.
Change-Id: I6a7b3708fadefff1919d70ab1b8bc345b3fbe81c
Partially-Implements: blueprint address-scopes
The configuration options come from oslo and the server
executable is usually wrapped in a service script, supplied
by packagers and/or deployment tools. Any extra documentation
available in tree is of relative value, and the fact that
this file has been virtually ignored ever since it was
added is a testament of that.
Let's stop its agony and wish it to rest in peace.
Closes-bug: #1520041
Change-Id: If5bba557526903b8064ee28628a21c3459ca85bc
This removes what's left of the nuage code and artifacts from the
neutron tree. All the vendor code is now in the
nuagenetworks/nuage-openstack-neutron repo on github.
Closes-Bug: #1518643
Change-Id: Ifbb9484f36a3e42c6039c42c7f8d0bcbd482bbf8
* Removed long term goals documentation (I don't see a need
to document these).
* Added and rearranged short term goals.
Change-Id: If494533cb6507f18b84a41b3f1daf42cd10d9f51
Some small changes - since the original paragraph didn't mention that
core is not required until the very last sentence.
Change-Id: I113371933754c109247c5f2b789cda135dce8563
Presents what instrumentation is available from VIFs in Nova,
Metering Lables and Rules, Linux Bridge, and OVS. Proposes
mappings for structures defined in RFC 2863 and RFC 4293 and
the method that will be followed for a data collection proof
of concept.
How to aggregate and consume these counters will be covered
in future patch sets that extend this devref.
Change-Id: I6c1ad0c4cf60d0069c5e057d77f75c12b04a020c
Partial-bug: #1475736
- This does NOT break other projects that rely on neutron.i18n,
as this change includes a debtcollector shim to maintain those
older entry points, until they can migrate.
- Also updates _i18n.py to the latest pattern defined by oslo_i18n
- Guidance and template are from the reference:
http://docs.openstack.org/developer/oslo.i18n/usage.html
Partially-Closes-Bug: #1519493
Change-Id: I1aa3a5fd837d9156da4643a367013c869ed8bf9d
Versioned Object push notifications require the server to be aware
of supported versions in the agents, since they are subscribed
to neutron-vo-<resource-type>-<version-number>.
During upgrade time, the server would need to downgrade and serialize
the objects across version subset, and send it to the fanout
queues for agent consumption.
One manual solution could be manual admin pinning, but we can do
better than that, making administrator lives easier if we provide
a reliable mechanism for remote version auto discovery.
Change-Id: I02b694137eb2d58e5f2f3e7631f0e4b90f7c17ad