yahoo-eng-team team mailing list archive

[Slawek Kaplonski <slawek@xxxxxxxxxxxx>]

Public bug reported:

Currently mechanism drivers in ML2 plugin can specify list of QoS rule types which are supported by driver. For example for openvswitch mech_driver it is "bandwidth_limit_rule" (which is only for egress traffic in fact) and "dscp_marking" rule.
Neutron API can return what rules are supported by get common set of supported rules from each loaded mechanism driver.
There are two problems with such simple check:
 - if rules are created or policy is applied to port there is no validation at all. It means that for example policy with dscp_marking rule can be applied to port bound with linuxbridge or sriov mech_drivers without any errors
 - there is no possibility that mechanism driver will support some rules only with specific parameters. For example bandwidth_limit_rule could have parameter "direction" with values "ingress" and "egress" and some of mechanism drivers could only supports bandwidth limit with direction=egress.

We propose change of how supported rule types are calculated and how validation works.
Supported rule types would be set of rules and list of parameters and values for those rules. This set will contain rules supported by at least one of loaded mechanism drivers. Example output from neutron could be:

admin@devstack-1:/opt/stack/neutron$ neutron qos-available-rule-types
+---------------------------------------------------------------------------------+-----------------+
| parameters                                                                      | type            |
+---------------------------------------------------------------------------------+-----------------+
| {u'dscp_mark': []}                                                              | dscp_marking    |
| {u'max_kbps': [], u'direction': [u'ingress', u'egress'], u'max_burst_kbps': []} | bandwidth_limit |
+---------------------------------------------------------------------------------+-----------------+

which means that:
* dscp_marking rule is supported with parameter dscp_mark and it can have any value
* bandwidth_limit rule is supported with parameters max_kbps and max_burst_kbps which can have any value and direction which can be ingress or egress only


Second change is change in validation of rules. During events like:
* port_update
* network_update
* policy_update
* rule_create
* rule_update
there will be called method from neutron.services.qos.notification_drivers.qos_base:QosServiceNotificationDriverBase.validate_policy_for_{port,network} which will raise exception if policy can't be applied on port or one of ports.
For ML2 plugin it will raise exception if policy will contain any rule which is not supported by mechanism driver used for port binding or by mechanism drivers used by specific binding:vnic_type if port is unbound.

** Affects: neutron
     Importance: Undecided
     Assignee: Slawek Kaplonski (slaweq)
         Status: New


** Tags: qos rfe

** Changed in: neutron
     Assignee: (unassigned) => Slawek Kaplonski (slaweq)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1586056

Title:
  Improve mechanism of validation if QoS rule is supported by mechasnim
  driver

Status in neutron:
  New

Bug description:
  Currently mechanism drivers in ML2 plugin can specify list of QoS rule types which are supported by driver. For example for openvswitch mech_driver it is "bandwidth_limit_rule" (which is only for egress traffic in fact) and "dscp_marking" rule.
  Neutron API can return what rules are supported by get common set of supported rules from each loaded mechanism driver.
  There are two problems with such simple check:
   - if rules are created or policy is applied to port there is no validation at all. It means that for example policy with dscp_marking rule can be applied to port bound with linuxbridge or sriov mech_drivers without any errors
   - there is no possibility that mechanism driver will support some rules only with specific parameters. For example bandwidth_limit_rule could have parameter "direction" with values "ingress" and "egress" and some of mechanism drivers could only supports bandwidth limit with direction=egress.

  We propose change of how supported rule types are calculated and how validation works.
  Supported rule types would be set of rules and list of parameters and values for those rules. This set will contain rules supported by at least one of loaded mechanism drivers. Example output from neutron could be:

  admin@devstack-1:/opt/stack/neutron$ neutron qos-available-rule-types
  +---------------------------------------------------------------------------------+-----------------+
  | parameters                                                                      | type            |
  +---------------------------------------------------------------------------------+-----------------+
  | {u'dscp_mark': []}                                                              | dscp_marking    |
  | {u'max_kbps': [], u'direction': [u'ingress', u'egress'], u'max_burst_kbps': []} | bandwidth_limit |
  +---------------------------------------------------------------------------------+-----------------+

  which means that:
  * dscp_marking rule is supported with parameter dscp_mark and it can have any value
  * bandwidth_limit rule is supported with parameters max_kbps and max_burst_kbps which can have any value and direction which can be ingress or egress only

  
  Second change is change in validation of rules. During events like:
  * port_update
  * network_update
  * policy_update
  * rule_create
  * rule_update
  there will be called method from neutron.services.qos.notification_drivers.qos_base:QosServiceNotificationDriverBase.validate_policy_for_{port,network} which will raise exception if policy can't be applied on port or one of ports.
  For ML2 plugin it will raise exception if policy will contain any rule which is not supported by mechanism driver used for port binding or by mechanism drivers used by specific binding:vnic_type if port is unbound.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1586056/+subscriptions