In addition to binding:vif_type, the neutron core plugin needs to
supply various information to nova's VIF driver, such as VIF security
details and PCI details when SR-IOV is being used. This information is
read-only, requires admin privileges, and is not intended for normal
users. Rather than add separate mechanisms throughout the stack for
each such requirement, the binding:capabilities port attibute, which
is a dictionary and is not currently not used by nova, is renamed to
binding:vif_details to serve as a general-purpose mechanism for
supplying binding-specific details to the VIF driver.
This patch does not remove or replace the CAP_PORT_FILTER boolean
previously used in binding:capabilities. A separate patch should
implement the specific key/value pairs carried by binding:vif_details
to implement VIF security. Another patch will implement the key/value
pairs needed for SR-IOV.
The ML2 plugin now allows the bound mechanism driver to supply the
binding:vif_details dictionary content, instead of just the
CAP_PORT_FILTER boolean previously carried by the binding:capabilities
DocImpact: Need to update portbinding extension API, but no impact on
user or administrator documentation.
Implements: blueprint vif-details
This patch adds support for requested vnic_type to be plugged to neutron port to ML2 plugin.
This patch contains:
1. New attribute 'binding:vnic_type' added to port binding extension.
Possible values are 'direct', 'macvtap' and 'normal'.
'binding:vnic_type' is allowed to be defined on port creation or changed
on port update by admin or tenant user.
'binding:vnic_type' can be also skipped in port defintion
2. Management of vnic_type by ML2 plugin, assuming default
3. Add 'vnic_type' to ml2_port_bindings DB table
4. Add supported vnic_types for MechanismDrivers that are capable to bind
5. Add DB migration script for ml2_vnic_type.
DocImpact: Need to update portbindings API docs and include in SR-IOV user docs
Implements: blueprint ml2-request-vnic-type
This is feature patch (3 of 3) that introduces support for
transitioning existing NSX-based deployments from the agent
based model of providing dhcp and metadata proxy services
to the new agentless based mode. In 'combined' mode, existing
networks will still be served by the existing infrastructure,
whereas new networks will be served by the new infrastructure.
Networks may be migrated to the model using a new CLI tool
provided, called 'neutron-nsx-manage'. Currently the tool
provides two admin-only commands:
neutron-nsx-manage net-report <net-id-or-name>
This will check that the network can be migrated and returns
the resources currently in use. And:
neutron-nsx-manage net-migrate <net-id-or-name>
This will move the network over the new model and deallocate
resources from the agent. Once a network has been migrated
there is no turning back.
Currently non-admin user cannot create a network with
shared=True. But the user can create the network and then
change the shared attribute to True.
This patch will no longer allow non-admin user to update a
network's shared value to True.
Updated policy for firewall_policy and firewall_rule to allow sharing
among tenants. Added a new firewall sharing rule to enable this.
Fixes: bug #1217103
The following commit adds the ability to associate multiple
different provider networks on a single network.
Implements blueprint map-networks-to-multiple-provider-networks
This a part of the blueprint bandwidth-router-label
This patch initiates the blueprint by adding base class
to associate labels and metering rules to tenant's routers.
This will enable the Cisco Nexus 1000V to integrate with the Cisco plugin
and be used to drive the realization of Neutron constructs.
Network profile and Policy profile are introduced as extended neutron
resources, while n1kv:profile_id is introduced as an extended attribute
for network and port objects. Necessary changes to the Cisco plugin are
made to accomodate Nexus 1000V as a configurable vswitch plugin.
Implements: blueprint cisco-plugin-n1k-support
Implements: blueprint quantum-fwaas
This is the first iteration of the FWaaS implementation and
is geared towards implementing the model that will be
required to at least address the reference implementation.
This iteration will not include implementation of the following
* grouping or dynamic objects
* application/service objects
implements blueprint service-type-framework-cleanup
* Defines logic and API for ServiceProvider - read-only entity
that admins provide in configuration and which is stored in memory
* ServiceType entity which maps to ServiceOfferings in new terms
is removed for now.
* Routed service insertion fixed to not to refer to service providers.
* In case configuration changes and some service providers are removed
then the resources must be cleanup in a special way (undeploy logical
resources). This is a matter of future work
* Add migration.
- adds simple chance scheduling on create pool operation
- adds PoolsLoadbalancerAgentBinding db table
- adds lbaas_agentscheduler extension to list pools hosted by a particular agent
and to get an agent hosting a particular pool
- adds agent notifiers mapping to AgentSchedulerDbMixin to make it easier
for services to add their agent notifiers to the core plugin
Implements blueprint lbaas-agent-scheduler
Part 2 of blueprint l3-ext-gw-modes
This patch extends the logic for building policy rule matches in order to
include sub-attributes as well. This logic will be leveraged by the
ext-gw-mode api extension.
This commit adds an API extension for NVP where the
NVP supported mac learning feature can be switched
on/off for a specific port. The attribute can be
True or False or omitted altogether.
Implements blueprint nvp-mac-learning-extension
This patch adds the l3 resources to policy.json. I tested changing the
rule to rule:admin_only for all the resources added and they were
enforced as expected.
Fixes bug 1186077
This patch introduces a new type of check whose aim is to fetch
the parent resource's owner only when a rule that explicitly needs
it needs to be checked.
This patch implements part #3 of this blueprint, according to its
It does so by allowing the view generator in the API layer to strip
off fields which do not satify authorization policies.
Also, some checks in unit tests for plugins relied on the
capability of the plugin to invoke directly the policy engine.
This checks have been removed and replaced by equivalent unit tests.
Finally, this patch required changes to most test cases for API
extensions in order to ensure the resource attribute map was
updated with the extension's attributes
related patch in nova:
Only OVS and linux bridge plugins now support this feature.
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
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.
This patch adds a new policy named 'context_is_admin' which defines
an admin user as a collection of roles or else. The quantum context
has been updated to check for this policy when setting the is_admin
This patch also adds a method for gathering 'admin' roles from policy
rules as current logic requires the context to be always populate with
the correct roles for admin rules, even when the context is implicitly
generated with get_admin_context or context.elevated.
Backward compatibility is ensuring by preserving the old behavior if
the 'context_is_admin' policy is not found in policy.json
This implements work item #1 of the blueprint.
This patch enables authZ checks for 'member actions' in the base
controller and removes explicit checks from l3_db.
This patch also addresses a small glitch in the policy engine which
was assuming the request always had a body.
This patch removes extra colons from policy.json.
Also, it fixes some checks in the nicira plugin which were not
passing correctly the target resource for the policy engine.
3rd part of blueprint quantum-scheduler
1. Allow networks to be hosted by certain dhcp agents.
Network to dhcp agent is a
many to many relationship. Provide a simple
scheduler to schedule a network randomly
to an active dhcp agent when a network or port is created.
2. Allow admin user to (de)schedule network to a
certain dhcp agent manually.
3. Allow routers to be hosted by a certain l3 agent.
Router to l3 agent is a many to one relationship.
Provide a simple scheduler to
schedule a router to l3 agent if the router is not
scheduled when the router is updated.
4. Auto schedule networks and routers to agents when agents
5. Only support ovs plugin at this point
Implements blueprint port-security-api-base-class
This patch also updates the _create_network/port in the unit tests
so that it does not remove false values from arg_list.
Fixes bug 1097527
This patch allows for managing service types through the API.
The default service type is specified in the configuration file.
The patch also provides a 'dummy' API extension, which uses the
'dummy' service plugin, as a PoC for usage of service type.
The dummy API extension is used in unit tests only.
The is part of the blueprint vif-plugging-improvements.
The patch adds an extension to Quantum that enables the plugin to
return VIF details.
At the moment it supports openvswitch and linuxbridge.
- adds admin-writable, world-readable router:external attribute to
the network object if L3 extension is loaded.
- prevents floating ips from being created unless network is external
- shortens L3 extensions alias from 'os-quantum-router' to 'router' to
make attribute extensions more readable.
- Need to add policy logic so non-admin users can always see external
networks without requiring that these networks are shared (since VMs can
always create ports on shared networks, but provider may want to have
externals networks that VMs cannot directly plug into.
- prevent delete_network in plugins from implying it returns something
- modify extensions.py so that exceptions during calls to
get_extended_resources() will actually be logged if unexpected.
- unset executable bit on test_iptables_manager.py to make sure tox
actually runs it.
Fixes bug 1043630
Port has no 'host_routes' attribute according to the latest V2 API
specification. So, policy check for 'host_routes' is not need any
more, just remove it in this patch.
Fixes bug 1039591
This patch will enable regular users to list subnets on a shared
network by exposing the subnet's "shared" attribute to the policy
engine, and letting it applying different rules if the subnet is
shared or private.
Implements blueprint quantum-v2-public-networks
This patch allows Quantum to handle public networks. It modifies the
API adding a new attribute to the network resource ('shared')
and enhances the policy engine in order to handle the behaviour of
the service wrt shared networks.
Policy.json specifies a default behaviour which can be changed by
the administrator, even at runtime.
Tests added to test_db_plugin validate 'obvious' behaviour - such as
that only the ports belonging to a given tenant should be returned
even when they are queried on a public network.
Tests added to test_policy instead validate the changes added to the
Initial provider extension implementation. Specify vlan_id using the
CLI with admin rights via "net-create --tenant_id <tenant-id>
<net-name> --provider:vlan_id <vlan-id>". Also includes
provider:vlan_id in reply messages for admins. The extension is
supported in the linuxbridge and openvswitch plugins.
Partially implements blueprint provider-networks.
Adds the policy openstack-common module and implements policy checks
for the v2 API. Note that this cut only addresses whole objects (i.e.,
a subnet or a network or a port), not specific fields within objects.
(This means that attributes are not filtered out based on policies.)
Implements blueprint authorization-support-for-quantum.