This patch introduces a criterion whereby sub-projects are considered
for inclusion (or exclusion) under the Neutron fold based on team
overlap, i.e. on who is driving the development of the sub-project
from inception to production.
For instance, Neutron team members may occasionally need to create
new repos for experimentation, or for the development of new
(potentially overlapping) functional areas to be incubated as an
integral part of the Neutron end-to-end system.
This patch is the last in a series that introduces criteria for
classification of projects for inclusion/exclusion to/out of the
Neutron 'stadium'. These criteria will always be applied jointly
when assessing a project for inclusion/exclusion at discretion of
the Neutron team.
Patches that complete the inclusion/exclusion process will follow
to discuss the rationale for inclusion/exclusion of the remainder
of the sub-projects.
Change-Id: Ie8e65a94ff9ec238e7c28a8b85d92835675d0c4c
Signed-off-by: Russell Bryant <rbryant@redhat.com>
Co-authored-by: Armando Migliaccio <armamig@gmail.com>
This guideline is intended to encourage new "advanced services" projects to
be set up as separate OpenStack project teams.
Change-Id: Ieb2e9efa782f2bcc951139558fbb7eecf3e6a46a
Signed-off-by: Russell Bryant <rbryant@redhat.com>
This patch adds an additional piece of criteria for Neutron sub-projects.
Projects that interface with Neutron on REST API boundaries only should
probably be separate. We propose Kuryr be split out based on this criteria.
We also document why Octavia stays for now.
Change-Id: Ic161409f6d1ca2efb623d9c7c2797d158a8094df
Signed-off-by: Russell Bryant <rbryant@redhat.com>
There has been a lot of discussion about how the current "Neutron
stadium" is working out. Consensus seems to be that it has grown
quickly beyond what makes sense as a single official OpenStack team.
The first step for scaling things back is agreeing on some additional
inclusion criteria that helps with drawing the line for what should be
an independent OpenStack project. See the following thread on the
mailing list for detailed discussion about this:
http://lists.openstack.org/pipermail/openstack-dev/2015-December/080865.html
This patch applies the first piece of criteria that can be used to decide if a
sub-project should be a separate OpenStack Project team. It also applies
the criteria against existing repos under Neutron.
Change-Id: I2f0198ba3174aacbe6b3098074f8c03cffd49438
Signed-off-by: Russell Bryant <rbryant@redhat.com>
When syncing up the Neutron repo list, I missed one. It was pointed out in
another review, so add it. This project seems inactive, but this patch is
simply to make this file match the current reality.
Change-Id: Idb29ab59eb06dd3b5d2ab6f985a360ca910cf2cb
Signed-off-by: Russell Bryant <rbryant@redhat.com>
The lbaas team considers neutron-lbaas, neutron-lbaas-dashboard,
and octavia as a unit that should not be separated. Update the
table to make that more clear.
Change-Id: I12302ef8678a3b6e6e9209de2fd24b77a5239de4
Signed-off-by: Russell Bryant <rbryant@redhat.com>
Commit 1105d732b2cb6ec66d042c85968d47fe6d733f5f disabled
auto scheduling for dvr routers because of the complexity
of DVR scheduling itself which led to a number of logical
and DB issues. Now after blueprint improve-dvr-l3-agent-binding
is merged DVR scheduling is almost no different from legacy
scheduling (no extra DVR logic required for auto scheduling)
so we can bring auto scheduling for DVR routers back.
This is better for consistency and improves UX.
Closes-Bug: #1543513
Change-Id: Ibf0263a711f0dbaf42fb59799ada79b6e896eca1
If bridge_mappings is configured in linuxbridge agent, it will now
determine agent_id which is based on MAC address of first device
from bridge_mappings in correct way.
Change-Id: I940379b2fd3b5f8c96cdf3b7a3c0da78532491f6
Closes-bug: #1542923
After dvr scheduling refactoring this method is only used in
l3_dvrscheduler_db. This patch also makes it private method.
Change-Id: Iac19d1244c63ec1b71360f9dd3b09c3b131e0ec8
Commit 07077bebb69da29994257d061d3a8d7ea9598c3d removed
enforcing that a subnet should be defined on a network. In
the case of IPv6 this is cool, but for V4 it is problematic.
The patch adds in a callback that enables the plugin to
determine validation policy.
The callback will be invoked prior to creating the gateway
port.
Closes-bug: #1543012
Change-Id: Idb7eeb5e0071aa5a2f302fba083504c4582edc1a
This patch includes changes that facilitate creation of subnetpools
and address scopes, as well as changes that make it easier to allocate
subnets from a subnetpool inside unit and API tests. These fixtures
are needed for testing BGP features, but have general utility in
in developing Neutron tests in the future.
Change-Id: I65749dac516e3ff23db50cbb7b832aa3039394e6
Partially-Implements: blueprint bgp-dynamic-routing
Currently, invoking any of the commands under neutron/cmd will trigger a
"No handlers could be found" error for Guru Meditation Report. This is
interupting the notify.sh script that is called by dibbler-client during the
IPv6 Prefix Delegation workflow.
This patch adds a logging handler to __init__.py to prevent the error.
Without the error message being thrown, neutron-pd-notify is once again
able to complete successfully when called by dibbler-client.
Change-Id: Iac3162f6b7e968c2f11fd8ef2a6e275242fb21ff
Closes-Bug: 1532053
This patch adds HA support for DVR centralized default SNAT
functionality to Neutron Server. For the agent side changes
another patch has been merged.
Salient changes here are:
- Schedule/de-schedule SNAT on multiple agents
- Enables
'router-create <router name> --ha True --distributed True'
Closes-bug: #1365473
Co-Authored-By: Adolfo Duarte <adolfo.duarte@hpe.com>
Co-Authored-By: Hardik Italia <hardik.italia@hpe.com>
Co-Authored-By: John Schwarz <jschwarz@redhat.com>
Co-Authored-By: Oleg Bondarev <obondarev@mirantis.com>
Change-Id: I6a19481d0e19b8a55f32199a27057bf777548b33
This patch makes add_tap_interface safe to race conditions
where the interface is removed in the middle of processing
by catching exceptions and checking to see if the interface
still exists. If it no longer exists it assumes the exception
was caused by the missing interface and returns False as it
would if the interface did not exist to begin with.
Change-Id: Ie0d89fc2584490b6985aee66da70bae027a130ed
Closes-bug: #1542972
When subnet or gateway port has been deleted concurrently, rpc call
to get_subnet_for_dvr will return an empty dict without any value.
ovs_dvr_neutron_agent should be more gracefull and at least log
warning message in that situation.
Change the existing error log to warning, because it is not a server
error, but a fact that should be noticed.
Change-Id: Icb3a57553a8b0eb635c0d85e2c60e7ce519893f6
Closes-bug: #1454921
The check to see if the prefix arg was specified would always be true, even if
the argument was not specified. This fixes it.
Change-Id: I60825c884e4d64aab2abc11d8da9bc1979baf0de
Signed-off-by: Russell Bryant <rbryant@redhat.com>
The extensions fields were not being added to the response being
sent back to the user for ports and networks that weren't from
ML2 extensions (e.g. availability zones). This created an
inconsistent response between creates and updates/gets. It also
resulted in incomplete data in the AMQP create notification emitted
in the API layer.
This patch adjusts ML2 to call the _apply_dict_extend_functions
method after creating ports and networks. To make this work, another
DB lookup to get the latest model state was necessary. However, this
is part of an already expensive operation (create) so the performance
impact should be minimal.
This issue stems from the fact that db_base_plugin_v2 does not
process extensions when its create_port, create_network methods
are called. This original skipping behavior was added back in
patch If0f0277191884aab4dcb1ee36826df7f7d66a8fa as a performance
improvement to deal with dictionary extension functions that
performed DB lookups. However, at this point the dictionary
extension functions should have been optimized to skip any DB
lookups to avoid the massive performance penalties they incur
during list operations.
An alternative to this patch was to adjust the db_base_plugin_v2
to stop skipping extensions. However, because this is usually
called by inheriting plugins before they process extensions
for the new port/network, the extensions do not yet have the
required information to extend the dict and will fail. So each
core plugin will need to apply similar logic to support extensions
that rely on the extend_dict functions.
Closes-Bug: #1541774
Change-Id: Iea2c0e7f9ee5eeae28b99797874ca8a8e5790ec2
