qos policy attached to network, qos_policy_id is reflecting on neutron net-show , but not on the port with neutron port-show

Bug #1649517 reported by Srinivas Balajinaidu
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Won't Fix
Wishlist
Unassigned

Bug Description

issue : qos policy attached to network, qos_policy_id is reflecting on neutron net-show , but not on the port with neutron port-show

(neutron) net-list
+--------------------------------------+------+-------------------------------------------------+
| id | name | subnets |
+--------------------------------------+------+-------------------------------------------------+
| 2fb0001c-98ba-4c67-9c81-2a19b05f4883 | net2 | ab1493c2-206a-4ac7-9818-f9aa61462399 2.2.2.0/24 |
| 3a8575c2-72dc-4602-a2e1-ab7eeb6421b7 | net1 | 7378f275-5069-4284-a34d-3dfc852015b9 1.1.1.0/24 |
+--------------------------------------+------+-------------------------------------------------+
(neutron)

(neutron) port-list
+-------------------------------------+-------+-------------------+--------------------------------------+
| id | name | mac_address | fixed_ips |
+-------------------------------------+-------+-------------------+--------------------------------------+
| 4330f8a8-6a88-4874-af29-f7defb2a60f | port1 | fa:16:3e:dd:a0:37 | {"subnet_id": "7378f275-5069-4284 |
| 2 | | | -a34d-3dfc852015b9", "ip_address": |
| | | | "1.1.1.8"} |
| c23db14e- | | fa:16:3e:d5:40:fa | {"subnet_id": "7378f275-5069-4284 |
| ea16-4f08-a0d5-884ef77eef2f | | | -a34d-3dfc852015b9", "ip_address": |
| | | | "1.1.1.2"} |
| d2e6a1c5-030b-4f75-b2cd- | port2 | fa:16:3e:30:29:45 | {"subnet_id": "7378f275-5069-4284 |
| f309f5ac9888 | | | -a34d-3dfc852015b9", "ip_address": |
| | | | "1.1.1.9"} |
| f6a624f8-b3c8-4865-a712-d2883e700f7 | | fa:16:3e:e1:99:d3 | {"subnet_id": "ab1493c2-206a- |
| 0 | | | 4ac7-9818-f9aa61462399", |
| | | | "ip_address": "2.2.2.2"} |
+-------------------------------------+-------+-------------------+--------------------------------------+

(neutron) qos-policy-list
+--------------------------------------+------+
| id | name |
+--------------------------------------+------+
| 48a4ac9a-729b-42ef-aab6-4b712193e4e2 | qos3 |
| 8f6aee1d-c981-44a5-8edb-32bd84e0b055 | qos2 |
| 94bf3722-2c1f-4c67-b288-0285f4b5690b | qos1 |
+--------------------------------------+------+

(neutron) net-update net1 --qos-policy qos1
Updated network: net1
(neutron)

------------------------------------------------------------------------------
Issue: policy is seen in net-show but not in port-show
------------------------------------------------------------------------------

+
(neutron) net-show net1
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | True |
| availability_zone_hints | |
| availability_zones | nova |
| created_at | 2016-12-13T13:12:49Z |
| description | |
| id | 3a8575c2-72dc-4602-a2e1-ab7eeb6421b7 |
| ipv4_address_scope | |
| ipv6_address_scope | |
| mtu | 1450 |
| name | net1 |
| port_security_enabled | True |
| project_id | dd4b9f1005e34daa9e2b8c77d4478bab |
| provider:network_type | vxlan |
| provider:physical_network | |
| provider:segmentation_id | 58 |
| qos_policy_id | 94bf3722-2c1f-4c67-b288-0285f4b5690b |
| revision_number | 8 |
| router:external | False |
| shared | False |
| status | ACTIVE |
| subnets | 7378f275-5069-4284-a34d-3dfc852015b9 |
| tags | |
| tenant_id | dd4b9f1005e34daa9e2b8c77d4478bab |
| updated_at | 2016-12-13T13:24:27Z |
+---------------------------+--------------------------------------+
(neutron)

(neutron) port-show port1
+-----------------------+--------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+--------------------------------------------------------------------------------+
| admin_state_up | True |
| allowed_address_pairs | |
| binding:host_id | ubuntu |
| binding:profile | {} |
| binding:vif_details | {"port_filter": true} |
| binding:vif_type | ovs |
| binding:vnic_type | normal |
| created_at | 2016-12-13T13:38:26Z |
| description | |
| device_id | 9c162538-220f-4645-aac4-6beafacbea94 |
| device_owner | compute:nova |
| extra_dhcp_opts | |
| fixed_ips | {"subnet_id": "7378f275-5069-4284-a34d-3dfc852015b9", "ip_address": "1.1.1.8"} |
| id | 4330f8a8-6a88-4874-af29-f7defb2a60f2 |
| mac_address | fa:16:3e:dd:a0:37 |
| name | port1 |
| network_id | 3a8575c2-72dc-4602-a2e1-ab7eeb6421b7 |
| port_security_enabled | True |
| project_id | dd4b9f1005e34daa9e2b8c77d4478bab |
| qos_policy_id | (not reflecting) |
| revision_number | 9 |
| security_groups | 7791107e-4582-417f-ba71-cde04f77a49b |
| status | ACTIVE |
| tenant_id | dd4b9f1005e34daa9e2b8c77d4478bab |
| updated_at | 2016-12-13T13:43:06Z |
+-----------------------+--------------------------------------------------------------------------------+
(neutron)

------------------------------------------------------------------------------
policy is applied to all the ports in the network , seen in ovs-vsctl
------------------------------------------------------------------------------
stack@ubuntu:~/devstack$ sudo ovs-vsctl list interface | grep ingress
ingress_policing_burst: 10000
ingress_policing_rate: 50000
ingress_policing_burst: 10000
ingress_policing_rate: 50000
ingress_policing_burst: 0
ingress_policing_rate: 0
ingress_policing_burst: 0
ingress_policing_rate: 0
ingress_policing_burst: 10000
ingress_policing_rate: 50000
ingress_policing_burst: 0
ingress_policing_rate: 0

Tags: qos rfe
Revision history for this message
Srinivas Balajinaidu (srinii15) wrote :
tags: added: qos
Revision history for this message
Miguel Angel Ajo (mangelajo) wrote :

QoS policy and port-security are very similar, but have different behaviour,

while with port-security, if you set it to False on a network, created ports will inherit the network value, and keep it set on the database.

So if you have net-A with port-security:False, and you create port-B on net-A, port-B will have port-security:False on the API and the database. If you then set net-A port-security:True, port-B will remain to port-security:False, since it was inherited at creation time.

In QoS, the behaviour is different:

If you have net-A with qos-policy:C, and you create port-B in net-A, your port will effectively behave with policy "C", but, that won't be inherited on the port-B database. When net-A is updated, for example to qos-policy:D, all ports in network (with no specific policy) will change to policy:D.

Given current behaviour, I would not expose the network-policy as qos-policy-id in the port. Because that'd be confusing, you couldn't look at the port, and know if it's overriding any network policy, or if it's just that it matches to have the same policy as the network.

I wonder if it could make sense to provide a "network-qos-inherited-policy-id" read only field, or something like that.

Changed in neutron:
importance: Undecided → Wishlist
Revision history for this message
Miguel Angel Ajo (mangelajo) wrote :

I'd close this as "Opinion", may be, and turn it into an RFE if you believe there's a use case. For now you can get the policy_id by checking the network.

The effective policy_id would be:

port.qos_policy_id or port.network.qos_policy_id

Changed in neutron:
assignee: nobody → Slawek Kaplonski (slaweq)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.openstack.org/419642

Changed in neutron:
status: New → In Progress
Revision history for this message
Miguel Angel Ajo (mangelajo) wrote :

Shall we make this an RFE?

Changed in neutron:
assignee: Slawek Kaplonski (slaweq) → Reedip (reedip-banerjee)
Revision history for this message
Reedip (reedip-banerjee-deactivatedaccount) wrote :

as per comment from Miguel in comment #5

tags: added: rfe
Changed in neutron:
assignee: Reedip (reedip-banerjee) → Slawek Kaplonski (slaweq)
Changed in neutron:
assignee: Slawek Kaplonski (slaweq) → Reedip (reedip-banerjee)
Changed in neutron:
assignee: Reedip (reedip-banerjee) → Slawek Kaplonski (slaweq)
Changed in neutron:
assignee: Slawek Kaplonski (slaweq) → Reedip (reedip-banerjee)
Changed in neutron:
assignee: Reedip (reedip-banerjee) → Slawek Kaplonski (slaweq)
Changed in neutron:
assignee: Slawek Kaplonski (slaweq) → Reedip (reedip-banerjee)
Changed in neutron:
assignee: Reedip (reedip-banerjee) → Slawek Kaplonski (slaweq)
Changed in neutron:
assignee: Slawek Kaplonski (slaweq) → Reedip (reedip-banerjee)
Changed in neutron:
assignee: Reedip (reedip-banerjee) → Slawek Kaplonski (slaweq)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron-lib (master)

Fix proposed to branch: master
Review: https://review.openstack.org/516574

Changed in neutron:
assignee: Slawek Kaplonski (slaweq) → Reedip (reedip-banerjee)
Changed in neutron:
status: In Progress → Triaged
Changed in neutron:
status: Triaged → In Progress
Changed in neutron:
status: In Progress → Triaged
Changed in neutron:
status: Triaged → In Progress
Changed in neutron:
status: In Progress → Triaged
Revision history for this message
YAMAMOTO Takashi (yamamoto) wrote :

i'm not sure if it's worth to have it in the server.
after all a user or client can query network the network by itself, right?

Revision history for this message
Reedip (reedip-banerjee-deactivatedaccount) wrote :

As discussed in the QoS weekly meeting:

"for the case when port inherits policy from network and don't have own policy then it is not clear that port have got any policy attached unless user does network-show for each port which he has to confirm which Network QoS policy is inherited by the port.The patch listed here adds additional field to port. Before this patch,there will be no policy-id if it is inherited from network, which may be a bit confusing to the user because though the port internally has a QoS policy, inherited by the network, it is not visible to the user."

Revision history for this message
Miguel Lavalle (minsel) wrote :

@Reedip,

Let's clarify this. Currently, if a port inherits its QoS policy from its network, the policy_id attribute of the port will be None. Is that correct?

Revision history for this message
YAMAMOTO Takashi (yamamoto) wrote :

alternatively the cli etc can automatically query network and show "effective qos policy" for users.
i guess you should provide a use case for which this should be done in the neutron server.

Revision history for this message
Reedip (reedip-banerjee-deactivatedaccount) wrote :

@minsel

> if a port inherits its QoS policy from its network, the policy_id attribute of the port will be None. Is that correct?

As per https://github.com/openstack/neutron/blob/master/neutron/core_extensions/qos.py#L112 , when the query against port would be made, if port doesnt have a policy associated with it, it would be None

Revision history for this message
Miguel Lavalle (minsel) wrote :

@Reedip,

Takashi's suggestion to fix this at the CLI level sounds promising to me. Why wouldn't it work? Do you have a use case where that wouldn't be a solution?

Revision history for this message
Miguel Lavalle (minsel) wrote :

This RFE was discussed on December 22nd drivers meeting. It was decided that this functionality can be solved in OSC with a fake field to the response. This field would be new one that doesn't override the current policy_id one. It might be named effective_policy_id. If port doesn't have a policy of its own, then:

qos_policy_id = None and effective_policy_id = whatever in network

if port has own policy, then both fields are the same

During the meeting it was also discussed whether there is a use case that requires this to be solved as an extension to the server. Is there such a use case?

Miguel Lavalle (minsel)
Changed in neutron:
status: Triaged → Won't Fix
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron (master)

Change abandoned by Slawek Kaplonski (<email address hidden>) on branch: master
Review: https://review.openstack.org/419642
Reason: As was discussed in comments to reported RFE on launchpad and on drivers meeting, this can be changed in OSC so this patch is not necessary anymore IMHO

Changed in neutron:
assignee: Reedip (reedip-banerjee) → nobody
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron-lib (master)

Change abandoned by Reedip (<email address hidden>) on branch: master
Review: https://review.openstack.org/516574
Reason: Issue was a Wont Fix

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.