← Back to team overview

yahoo-eng-team team mailing list archive

[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