Bug 1652428 - [RHOSP14] [OpenDaylight] Unable to create neutron QOS_DSCP policy after Overcloud deployment with OpenDaylight.
Summary: [RHOSP14] [OpenDaylight] Unable to create neutron QOS_DSCP policy after Overc...
Keywords:
Status: CLOSED DUPLICATE of bug 1329358
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: opendaylight
Version: 14.0 (Rocky)
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: lpeer
QA Contact: Noam Manos
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-22 04:20 UTC by Pradipta Kumar Sahoo
Modified: 2018-11-22 13:46 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-22 13:46:47 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Pradipta Kumar Sahoo 2018-11-22 04:20:10 UTC
Description of problem:
Unable to create neutron QOS_DSCP policy after Overcloud deployment with OpenDaylight.


Version-Release number of selected component (if applicable):
Red Hat OpenStack 14
OpenDaylight

How reproducible:
Lab Environment


Steps to Reproduce:
1. Deployment has completed with following script where it included with odl-dscp-marking-inheritance.yaml template

#!/bin/bash

openstack overcloud deploy \
--timeout 200 \
--templates /usr/share/openstack-tripleo-heat-templates \
--stack overcloud \
--libvirt-type kvm \
--ntp-server clock.redhat.com \
-e /home/stack/virt/config_lvm.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e /home/stack/virt/network/network-environment.yaml \
-e /home/stack/virt/inject-trust-anchor.yaml \
-e /home/stack/virt/hostnames.yml \
-e /home/stack/virt/debug.yaml \
-e /home/stack/virt/nodes_data.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-opendaylight.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/disable-telemetry.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/odl-dscp-marking-inheritance.yaml \
-e ~/containers-prepare-parameter.yaml


2. In Netvirt by default in QOS_DSCP table is avaible in RHOSP14
 90:QOS_DSCP

3. In Overcloud controller, there is no QOS service plugin has enabled for neutron.
@controller-0 ~]# grep ^[^#] /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf | grep qos
@controller-0 ~]# grep ^[^#] /var/lib/config-data/puppet-generated/neutron/etc/neutron/plugins/ml2/ml2_conf.ini | grep -i qos

Actual results:
 Due to the above issue neutron api doesn't find resource to create QOS DSCP.
	$ neutron --debug qos-policy-create dscp-marking
	<..trim..>
	DEBUG: keystoneauth.session RESP: [404] Content-Length: 103 Content-Type: application/json Date: Thu, 22 Nov 2018 03:57:12 GMT X-Openstack-Request-Id: req-2af9c798-6a5a-4c0c-9a9d-085b8bcf2011
	DEBUG: keystoneauth.session RESP BODY: {"NeutronError": {"message": "The resource could not be found.", "type": "HTTPNotFound", "detail": ""}}
	DEBUG: keystoneauth.session POST call to network for http://10.0.0.102:9696/v2.0/qos/policies used request id req-2af9c798-6a5a-4c0c-9a9d-085b8bcf2011
	DEBUG: neutronclient.v2_0.client Error message: {"NeutronError": {"message": "The resource could not be found.", "type": "HTTPNotFound", "detail": ""}}
	ERROR: neutronclient.shell The resource could not be found.
	Neutron server returns request_ids: ['req-2af9c798-6a5a-4c0c-9a9d-085b8bcf2011']
	Traceback (most recent call last):
	  File "/usr/lib/python2.7/site-packages/neutronclient/shell.py", line 531, in run_subcommand
	    return run_command(cmd, cmd_parser, sub_argv)
	  File "/usr/lib/python2.7/site-packages/neutronclient/shell.py", line 68, in run_command
	    return cmd.run(known_args)
	  File "/usr/lib/python2.7/site-packages/neutronclient/neutron/v2_0/__init__.py", line 335, in run
	    return super(NeutronCommand, self).run(parsed_args)
	  File "/usr/lib/python2.7/site-packages/cliff/display.py", line 116, in run
	    column_names, data = self.take_action(parsed_args)
	  File "/usr/lib/python2.7/site-packages/neutronclient/neutron/v2_0/__init__.py", line 417, in take_action
	    data = obj_creator(body)
	  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 1813, in create_qos_policy
	    return self.post(self.qos_policies_path, body=body)
	  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 359, in post
	    headers=headers, params=params)
	  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 294, in do_request
	    self._handle_fault_response(status_code, replybody, resp)
	  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 269, in _handle_fault_response
	    exception_handler_v20(status_code, error_body)
	  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 93, in exception_handler_v20
	    request_ids=request_ids)
	NotFound: The resource could not be found.
	Neutron server returns request_ids: ['req-2af9c798-6a5a-4c0c-9a9d-085b8bcf2011']


Expected results:
The following parameter "OpenDaylightInheritDSCPMarking" is required to update all prerequisite configuration for neutron QoS services for DSCP.

$ cat /usr/share/openstack-tripleo-heat-templates/environments/odl-dscp-marking-inheritance.yaml
# This flag enables copying of DSCP markings to VXLAN tunnel header when
# OpenDaylight is enabled.
parameter_defaults:
  OpenDaylightInheritDSCPMarking: true

Additional info:
Raised following doc bug to update the QOS_DSCP validation steps
https://bugzilla.redhat.com/show_bug.cgi?id=1652192

Comment 1 Mike Kolesnik 2018-11-22 13:46:47 UTC
Hi Pradipta,

QoS is currently not a supported feature of ODL (That we ship).
This is planned to be supported as part of this RFE - Bug 1329358 

The DSCP inheritance feature AFAIK is only for a case where the DSCP has been set in the header of the encapsulated packet, and thus the VXLAN packet of the overlay should inherit the value from the header.
It doesn't deal with, nor does it guarantee, that QoS feature from Neutron are supported, but if you have an instance that sends a packet with DSCP value it should propagate to the overlay (Usually this should be a VNF).

*** This bug has been marked as a duplicate of bug 1329358 ***


Note You need to log in before you can comment on or make changes to this bug.