yahoo-eng-team team mailing list archive

[OpenStack Infra <1586056@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/426946
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=e2226fe373dfde74e8fc9e64ad65100e1c5de98b
Submitter: Jenkins
Branch:    master

commit e2226fe373dfde74e8fc9e64ad65100e1c5de98b
Author: Sławek Kapłoński <slawek@xxxxxxxxxxxx>
Date:   Mon Jan 30 21:56:38 2017 +0000

    Improve validation of supported QoS rules
    
    New way of validation of QoS policy can be applied on port/network based on
    port_types. It can validate if port can support rule by rule_type and also by
    rule parameters or some values of parameters.
    
    For example bandwidth_limit_rule can have parameter "direction" with
    possible values "ingress" and "egress". Some of mechanism drivers can support
    only one of those directions.
    
    If user will try to apply policy with rule unsupported by port_type then it
    will get error message and policy will not be applied.
    Such validation is made during:
    * port create
    * port update
    * network update
    * QoS rule create
    * QoS rule update
    
    Co-Authored-By: Miguel Angel Ajo <majopela@xxxxxxxxxx>
    
    Implements blueprint qos-rules-validation
    Closes-Bug: #1586056
    
    Change-Id: I75bd18b3a1875daa5639dd141fb7bbd6e1c54118


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
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:
  [RFE] Improved validation mechanism for QoS rules with port types

Status in neutron:
  Fix Released

Bug description:
  Currently neutron API can return what rules are supported, in the
  context of ML2: by returning the minimum subset of rules supported by
  all mechanism drivers.

  Mechanism drivers in ML2 plugin can specify a list of QoS rule types
  which are supported. For example openvswitch mech_driver will report
  "bandwidth_limit_rule" (which is only for egress traffic in fact) and
  "dscp_marking" rule.

  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 changes to how supported rule types are calculated and how
  validation works.

  Incompatible configurations or settings should be spotted as soon as possible, and stopped at API level with a clear explanation of what's going on. On corner cases where this can't be determined until bind time, binding should fail so the administrator won't have the wrong perception of the all the policy rules being applied, where it's not the case. Such Validation of rules should be made 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