neutron

Commit Graph

Author	SHA1	Message	Date
Brian Haley	7594bb0627	Remove the dependency on the "mock" package Now that we are python3 only, we should move to using the built in version of mock that supports all of our testing needs and remove the dependency on the "mock" package. This patch moves all references to "import mock" to "from unittest import mock". It also cleans up some new line inconsistency. Fixed an inconsistency in the OVSBridge.deferred() definition as it needs to also have an *args argument. Fixed an issue where an l3-agent test was mocking functools.partial, causing a python3.8 failure. Unit tests only, removing from tests/base.py affects functional tests which need additional work. Change-Id: I40e8a8410840c3774c72ae1a8054574445d66ece	3 years ago
Bence Romsics	258eebea71	Locate RP-tree parent by hypervisor name Previously we assumed that we can look up the resource provider (created by nova) to be used as the parent of the agent and physical NIC resource provider tree by the name set in the config option DEFAULT.host. This assumption was wrong. While nova-compute's DEFAULT.host and neutron-agent's DEFAULT.host must match for port binding to work, the root resource provider created by nova does not belong to the compute host (where nova-compute runs) but it belongs to the compute nodes (i.e. hypervisors). Actually there may be multiple compute nodes managed by a single nova-compute (think of ironic). Plus the value of DEFAULT.host and the compute node's ID may be different even when nova-compute manages a hypervisor on the same host because of various deployment considerations. For example when tripleo does not manage the undercloud (so a libvirt hypervisor returns the plain hostname), but the same tripleo enforces it's host naming conventions in nova's and neutron's DEFAULT.host settings. This change enables neutron to use the hypervisor name to locate the root of the resource provider tree. We introduce a new configuration option for (1) ovs-agent: resource_provider_hypervisors, for example: [ovs] bridge_mappings = physnet0:br-physnet0,... resource_provider_bandwidths = br-physnet0:10000000:10000000,... resource_provider_hypervisors = br-physnet0:hypervisor0,... (2) sriov-agent: resource_provider_hypervisors, for example: [sriov_nic] bridge_mappings = physnet1:ens5,... resource_provider_bandwidths = ens5:10000000:10000000,... resource_provider_hypervisors = ens5:hypervisor1,... For both agents 'resource_provider_hypervisors' values default to socket.gethostname() for each key in resource_provider_bandwidths. We try to not block later developments in which one neutron agent may manage devices on multiple hosts. That's why we allow the each physdev to be associated with a different hypervisor. But here we do not try to solve the problem that the natural physdev identifiers may not be unique accross multiple hosts. We leave solving this problem to whoever wants to implement an agent handling devices of multiple hosts. (3) We extend report_state message's configurations field alike: { 'bridge_mappings': {'physnet0': 'br-physnet0'}, 'resource_provider_bandwidths': { 'br-physnet0': {'egress': 10000000, 'ingress': 10000000}}, 'resource_provider_hypervisors': {'br-physnet0': 'hypervisor0'}, ... } (4) In neutron-server we use report_state.configurations.resource_provider_hypervisors.PHYSDEV when selecting parent resource provider for agent and physdev RP-tree. When not available in the message we fall back to using report_state.host as before. Since we only changed the free-format configurations field of the report_state message rpc version is not bumped and we expect this change to be backported to stein and train. Change-Id: I9b08a3a9c20b702b745b41d4885fb5120fd665ce Closes-Bug: #1853840	3 years ago
Rodolfo Alonso Hernandez	749b33e41b	Check in "_update_segmentation_id" that the mech_driver has an agent In [1] it is assumed that all mechanism drivers have an agent, but the mech driver API [2] doesn't enforce it. VIF types will be retrieved only from those mechanism drivers with an associated agent. [1]https://review.openstack.org/#/c/633165/20/neutron/plugins/ml2/plugin.py@814 [2]https://github.com/openstack/neutron-lib/blob/stable/stein/neutron_lib/plugins/ml2/api.py#L37 Change-Id: I5c334f31259871ed5251d5d4a2ba8cae36bd2355 Closes-Bug: #1824346	4 years ago
Zuul	51fbd1e549	Merge "Fail placement sync if _get_rp_by_name() fails"	4 years ago
Takashi NATSUME	86b3993cee	Fix misuse of assertTrue/assertFalse Change-Id: I247705feeb71e20ad5260b0ca1da08de7290ba6e Closes-Bug: #1819982	4 years ago
Bence Romsics	732dbdaf5e	Fail placement sync if _get_rp_by_name() fails The Placement sync process involves some input from Placement first. That is the UUID of the compute host RP. This is a remote call just like the Placement updates we send later and it also may fail in all the usual ways of remote calls. We need to fail the sync procedure if this remote call fails. Previously I had the mistaken belief that if I set the parent_uuid to None that will be an invalid call rejected by Placement. But no, that's a valid call and creates a resource provider without a parent. That is the neutron managed resource providers will be in their own resource provider tree instead of the compute host's resource provider tree. In this change we make sure to handle the failure of getting the compute host RP properly. We must not continue with the updates. And we must set the agent's resources_synced to False. Change-Id: Ie6ad33e2170c53a16c39a31a8d7f6496170a90ce Closes-Bug: #1818683	4 years ago
Bence Romsics	9e8e987e6c	Placement reporting service plugin This service plugin synchronizes ML2 mechanism driver agents' resource information to Placement. To use this service an agent must add 'resource_provider_bandwidths' to the 'configurations' field of its RPC heartbeat. It also may add 'resource_provider_inventory_defaults' to fine tune Placement inventory parameters. Again to use this service a mechanism driver must implement get_standrd_device_mappings() and allocate a UUID as mechanism driver property 'resource_provider_uuid5_namespace'. The synchronization is triggered by: * any new agent object in the DB * restart of an agent (via 'start_flag' in the RPC heartbeat) * if an agent's 'resources_synced' attribute is not True (None/False) The latter should autoheal transient errors of the synchronization process. That is if a sync attemp fails then we store resources_synced=False which triggers a sync retry at each new heartbeat message until a sync attempt finally succeeds and we can set resources_synced=True. Since this code functionally depends on ML2 we can also consider making it part of ML2, but at the moment it is a service plugin for better decoupling. Even if you load the service plugin the logic gracefully degrades for heartbeat messages not containing resource provider info. If needed the sync can be forced in multiple ways. First, if you restart an agent then the RPs belonging to that agent will be re-synced. You may also delete the agent by 'openstack network agent delete' and let the next heartbeat message re-create the agent object. On re-creation the RPs belonging to that agent will be re-synced. On the other hand a neutron-server restart does not trigger a re-sync in any way. Depending on the trade-off between the admin's needs to force re-syncs and the performance of (not absolutely necessary) Placement updates re-sync conditions may be further fine tuned. Example config for neutron-server: neutron.conf: [DEFAULT] service_plugins = placement Change-Id: Ia1ff6f7559ab77913ddb9c3b134420a401b8eb43 Co-Authored-By: Lajos Katona <lajos.katona@ericsson.com> Depends-On: https://review.openstack.org/586567 Partial-Bug: #1578989 See-Also: https://review.openstack.org/502306 (nova spec) See-Also: https://review.openstack.org/508149 (neutron spec)	4 years ago

7 Commits (0634dcc6d0f08c18c69a2c360a2c5c0581ec7bb6)