yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #55261
[Bug 1614728] [NEW] qos: rule list in policy is too difficult to use
Public bug reported:
The format of qos policy should be something like
{"policy": {"rules": {"bandwidth_limit": {...}, "dscp_marking": {...}}}}
https://review.openstack.org/#/c/207043/
The patch changed the format of qos policy to something like this
{"rules": [{"type": "bandwitdh_limit", ...}, {"type": "dscp_marking", ...}, ]}
with the rationale that there should be zero-or-one rule per each rule-type.
But the format has the following issues
- there is no guarantee that there is at most one rule per rule-type
In order to verify that, the list has to be scanned.
- When agent(or backend) programs switch for specific rule-type,
it has to scan the list to find a rule of a give rule-type
- the format is unfriendly to parser or external tools.(In my case java jaxb)
The actual variable type of rule needs to be determined by reading ahead
"type". Then the rule needs to be parsed again.
So the following format is better
{"rules": {"bandwidth_limit": {...}, "dscp_marking": {...}}}
- it is guaranteed that there is zero-or-one rule per rule-type
- it's easy to find a rule of a given rule-type
- parser easily determine variable-type.
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1614728
Title:
qos: rule list in policy is too difficult to use
Status in neutron:
New
Bug description:
The format of qos policy should be something like
{"policy": {"rules": {"bandwidth_limit": {...}, "dscp_marking": {...}}}}
https://review.openstack.org/#/c/207043/
The patch changed the format of qos policy to something like this
{"rules": [{"type": "bandwitdh_limit", ...}, {"type": "dscp_marking", ...}, ]}
with the rationale that there should be zero-or-one rule per each rule-type.
But the format has the following issues
- there is no guarantee that there is at most one rule per rule-type
In order to verify that, the list has to be scanned.
- When agent(or backend) programs switch for specific rule-type,
it has to scan the list to find a rule of a give rule-type
- the format is unfriendly to parser or external tools.(In my case java jaxb)
The actual variable type of rule needs to be determined by reading ahead
"type". Then the rule needs to be parsed again.
So the following format is better
{"rules": {"bandwidth_limit": {...}, "dscp_marking": {...}}}
- it is guaranteed that there is zero-or-one rule per rule-type
- it's easy to find a rule of a given rule-type
- parser easily determine variable-type.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1614728/+subscriptions
Follow ups