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 <sla...@kaplonski.pl>
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 <majop...@redhat.com>
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
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
