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
This adds a new tox environment, genconfig, which generates sample
neutron core configuration file using oslo-config-generator.
Updates to some configuration option help messages to reflect useful
details that were missing in the code but were present in config files.
It also adds details to devref on how to update config files.
Partially-Implements: blueprint autogen-neutron-conf-file
DocImpact
Change-Id: I1c6dc4e7d479f1b7c755597caded24a0f018c712
Closes-bug: #1199963
Co-Authored-By: Louis Taylor <louis@kragniz.eu>
* Display more contents in the top page.
It is useful to access various things from the top page.
The contents after this change looks reasonable.
* Remove "Indices and tables" section in policies and stadium index.
They are unnecessary.
Change-Id: I49a966ce96af107c6f17f4caa73f9a634db37e18
Milestone assignment is another mumbo jumbo effort in open source.
Artificially setting milestones implies that someone can reliably
predict the future when no-one is really in full control.
For this reason let's make clear that we optmistically target the
current milestone for work that is supposed to start asap, and
complete sooner rather than later. Rolling over until the work is
complete is the natural course of action.
Dashboards [1] then capture the entire workload (BP and RFE) for
the entire release cycle, and that's helpful to provide to overall
view.
[1] https://launchpad.net/neutron/+milestone/<release>-?
Change-Id: Idb2d84ba683d2c8f1460e7bf0ff76d457cf42bce
This adds a new 'standardattributes' table and adds a foreign-key
references from ports, subnets, networks, subnetpools, routers,
securitygroups, and floatingips to this table.
This will make it easy to add new things to the schema like
timestamp fields or anything else that applies to multiple types
of Neutron resources. The new fields would just be added to the
'neutronresources' table instead of being duplicated across each
resource's table. Or, if the the relationship is 1-to-many (e.g. tags),
the new association table would be related to the 'standardattribute'
table.
Related-Bug: #1496802
Change-Id: Iaa3ba81a7e9cae09cea153720b29879d8cc9a080
The page is intended to describe current upgrade features Neutron
supports, lay out potential improvements, describe testing strategy for
existing and planned upgrade features, and provide guidelines to
reviewers on where to look for potential upgrade breakages in proposed
patches.
Change-Id: I22e55bb2fe32b32d12fa5889b91ecb9f92b3e6a6
Provide tag for bugs that affect the role based access control
and the Neutron policy layers (driven by policy.json).
Change-Id: Ia4259d53974996a83d380e778309aea2d7cb29cd
