For the most part, the dhcp agent uses the root_helper setting from the [AGENT]
section of /etc/quantum/quantum.conf. However, in a couple of spots, the
root_helper setting from the [DEFAULT] section of /etc/quantum/dhcp_agent.ini
was being used.
Thierry Carrez [Mon, 6 May 2013 15:02:39 +0000 (17:02 +0200)]
Import recent rootwrap features in local rootwrap
Import features developed in oslo-rootwrap during the Grizzly cycle (and
recently in havana) into quantum-rootwrap. This is the first step toward
using the common oslo-rootwrap into Quantum: the goal being to make both
implementations converge, we should avoid making local changes (and push
any required change into oslo-rootwrap instead from now on).
New features include:
- Optional logging (use_syslog)
- Searching for executables in a specified binary path (exec_dirs)
- New path-based PathFilter
Those features required a refactoring in the way executables are matched
and in configuration loading.
Aaron Rosen [Tue, 7 May 2013 03:21:57 +0000 (20:21 -0700)]
Fix 500 raised on disassociate_floatingips when out of sync
If one deletes NAT rules directly from NVP and not through quantum,
an error will be raised when deleting a port that is associated with
the floating ip. This patch catches the NotFound exception and logs
it so that the port can successfully be deleted.
Log msg for load policy file only if the file is actually loaded
The Load entry was previousy in init(), whereas it should have
been in _set_rules() which is invoked only when policies are
(re)loaded from the json file.
Previously the NVP plugin would query NVP for the quantum port id that was
stored in the port as a tag in NVP. Later, a look up table was added in order
to directly look up the ID without having to go to NVP. The problem that can
arise is that if a port was created in folsom before this lookup table was
added and then deleted from NVP directly an error will be raised when calling
update_port(). This patch fixes this potential problem.
Dane LeBlanc [Wed, 10 Apr 2013 22:23:37 +0000 (18:23 -0400)]
blueprint cisco-plugin-exception-handling
Improvements to exception handling in the Cisco plugins. Changes
include:
- Added mapping of Cisco exceptions to HTTP codes
(extension to FAULT_MAP).
- Removed several unused Cisco exception definitions.
- Added several new Cisco exceptions for fault conditions.
- Added several rollbacks for various sequential operations, e.g.:
* Create port: Nexus sub-plugin fails after OVS sub-plugin success
* Create port: Nexus switch conig fails after adding binding to
Nexus binding database
* Delete port: OVS sub-plugin fails after Nexus sub-plugin success
- Delete Port: Reversed order of OVS/Nexus sub-plugin calls so that
it is done in the reverse order as is done for create port.
- Removed several empty except/raise blocks
- Delete network: Removed call to Nexus sub-plugin delete_network,
since that is a no-op.
- Removed a block of unused code in model's create_network method.
- Added several unit testcases, including patching of OVS, Cisco
and Nexus config.
- Remove CISCO_TEST configuration from cisco plugin
config .ini file.
Instead of loading security group associations with a separate query
each time a port is loaded from the database, perform the load operation
with a join using a joined sqlalchemy relationship.
Also, this patch removes the need for invoking the mixin method
'extend_port_dict_security_group' from the plugin code.
Roman Podolyaka [Fri, 26 Apr 2013 15:27:39 +0000 (18:27 +0300)]
Fix usage of Query.all() and NoResultFound
SQLAlchemy Query.all() method doesn't raise NoResultFound
exception in case if no result is found but rather returns
an empty list. So this pattern which is common for our code
doesn't make sense and should be fixed:
Mark McLoughlin [Thu, 2 May 2013 09:31:16 +0000 (10:31 +0100)]
Copy the RHEL6 eventlet workaround from Oslo
Tests in oslo-incubator now need the horrendous hack to workaround an
issue with eventlet on RHEL6. We've moved the patch_tox_venv tool
and redhat-eventlet.patch into oslo-incubator, so add them to
openstack-common.conf.
Aaron Rosen [Thu, 2 May 2013 00:12:11 +0000 (17:12 -0700)]
Allow admin to delete default security groups
Previously there was no way to delete a default security groups which
isn't ideal if you want to clean up after deleting a tenant. This patch
allows default security groups to be deleted by the admin.
For a particular NVP extension, a database entry was being populated
in the plugin's __init__ method. The entry was added with an admin
context. Grabbing the context caused the policy engine to load before
all the extension were loaded, so rule on extended attribute
were not being parsed correctly.
This cause checks on external networks to fail always.
Fix 'null' response on router-interface-remove operation
To avoid a 'null' response body, the delete operation returns a response
that is consistent with its add counterpart, i.e. we return the router
id with details about the interface being affected by the operation, as
well as the tenant id.
A unit test is added to ensure that the right body is returned and minor
adjustments have been made to the plugins affected by the change.
Long-term, a delete operation should really return 204 w/o a body, but
this requires some major rework of the WSGI handling within Quantum.
This is an interim solution that deals with an 'ugly' response body,
whilst keeping backward compatibility.
Remove calls to policy.enforce from plugin and db logic
Blueprint make-authz-orthogonal
This patch implementes item #2 of the blueprint
Remove calls to policy.enforce when the policy check can be performed
safely at the API level, and modify policy.json to this aim.
This patch does not address enforce calls in the agent scheduler
extension, as that extension is currently not defined as a quantum.v2.api
resource class.
This patch also adds an API-level test case for the provider networks
extension, which was missing in Quantum and was necessary to validate
the API behaviour with the default policy settings.
Roman Podolyaka [Thu, 25 Apr 2013 13:15:59 +0000 (16:15 +0300)]
Use Query instances as iterables when possible
A Query.all() call creates a list of a DB query results.
We can actually use a Query instance as an iterable and
thus avoid creation of a list if we just need to iterate
over those values only once.
This patch replacest the nvp_controller_connection configuration option
with a set of options more intutitive to user which also avoid
repetitions in ini files.
In order to simplify the configuration of the plugin, this patch also
removes named clusters. As the plugin supports a single cluster at
the moment, this can be simply specified in the [DEFAULT] configuration
section.
Also, this patch restrucures nvp_cluster.NvpCluster so that per-cluster
configuration options are not store anymore multiple times.
* Update veth pair creation to set the namespace of the peer
device on creation rather than subsequently adding it to the
namespace.
* This change supports kernels with limited namespace support
(e.g. RHEL 6.5) so long as ovs_use_veth is set to True.
* Addresses bug 1171727
Code Review / openstack-build / neutron-build.git / log