[Starlingx-discuss] Question about patch upstreaming for 1e9a089

Wed Oct 17 13:43:12 UTC 2018

Hi Huifeng,
What is the behavior if you modify the policy to None (using openstack network set --no-qos-policy <network>)?

-Matt

From: Le, Huifeng [mailto:huifeng.le at intel.com]
Sent: Wednesday, October 17, 2018 4:52 AM
To: Peters, Matt; Legacy, Allain
Cc: starlingx-discuss at lists.starlingx.io
Subject: RE: Question about patch upstreaming for 1e9a089

Matt,

Yes, your thought is correct - the check is not using individual property rule.
When creating network with a qos_policy_id, neutron will try to get the qos policy object within current context (e.g. by QosCoreResourceExtension. _get_policy_obj) then raises QosPolicyNotFound exception if qos_policy_id is not owned by the project.

During my test, I can see below error raised by neutron:
{"NeutronError": {
   "message": "QoS policy bda58768-7785-4ed3-b9b1-768d7979cc70 could not be found.",
   "type": "QosPolicyNotFound",
   "detail": ""
}}

Best Regards,
Le, Huifeng

From: Peters, Matt [mailto:Matt.Peters at windriver.com]
Sent: Tuesday, October 16, 2018 10:13 PM
To: Le, Huifeng <huifeng.le at intel.com>; Legacy, Allain <Allain.Legacy at windriver.com>
Cc: starlingx-discuss at lists.starlingx.io
Subject: Re: Question about patch upstreaming for 1e9a089

I was specifically referring to the network attribute that refers to the QoS policy ID, rather than the RBAC rules related to the policies themselves.  I don’t see anything in the policy.json that restricts the setting of the network attribute, so I am assuming it is falling back to the network entity policy itself rather than an individual property rule.

From: "Le, Huifeng" <huifeng.le at intel.com<mailto:huifeng.le at intel.com>>
Date: Tuesday, October 16, 2018 at 10:08 AM
To: Allain Legacy <Allain.Legacy at windriver.com<mailto:Allain.Legacy at windriver.com>>, "Peters, Matt" <Matt.Peters at windriver.com<mailto:Matt.Peters at windriver.com>>
Cc: "starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>" <starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>>
Subject: RE: Question about patch upstreaming for 1e9a089

Matt & Allain,

I think it is the current upstream design (https://docs.openstack.org/neutron/latest/admin/config-qos.html): “QoS policies are only created by admins with the default policy.json. Therefore, you should have the cloud operator set them up on behalf of the cloud projects.”

From the default policy.json, e.g. “create/update/delete” operation is for admin only and “get” operation is for any user. Do you see any gap with this design?
"create_policy": "rule:admin_only",
"get_policy": "rule:regular_user",
"update_policy": "rule:admin_only",
"delete_policy": "rule:admin_only",

Best Regards,
Le, Huifeng

From: Legacy, Allain [mailto:Allain.Legacy at windriver.com]
Sent: Tuesday, October 16, 2018 8:23 PM
To: Peters, Matt <Matt.Peters at windriver.com<mailto:Matt.Peters at windriver.com>>; Le, Huifeng <huifeng.le at intel.com<mailto:huifeng.le at intel.com>>
Cc: starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>
Subject: RE: Question about patch upstreaming for 1e9a089

I am not sure.  The qos_policy_id attribute does not have “enforce_policy” set in its attribute definition so I am going to guess that there is no checking at all for it.   I don’t have a system setup to test this at the moment, but I am going to guess that you could end up attaching a network to a qos_policy_id that is owned by a different tenant.  If so, then that is an issue that should be addressed.

Allain

Allain Legacy, Software Developer, Wind River
direct 613.270.2279  fax 613.492.7870 skype allain.legacy
350 Terry Fox Drive, Suite 200, Ottawa, Ontario, K2K 2W5

[WIND]<http://www.windriver.com/>

From: Peters, Matt [mailto:Matt.Peters at windriver.com]
Sent: Monday, October 15, 2018 12:55 PM
To: Le, Huifeng
Cc: starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>
Subject: Re: [Starlingx-discuss] Question about patch upstreaming for 1e9a089

Hi Allain,
Do you know why the standard qos_policy_id attribute of the network would not hit this problem?  I don’t even see them reference this field in the policy.json, so does it just permit anything to be changed by the tenant unless it is explicitly defined?

http://crucible.wrs.com/changelog/CGCS_github_neutron?cs=1e9a089

-Matt

From: Le, Huifeng [mailto:huifeng.le at intel.com]
Sent: Sunday, October 14, 2018 10:24 PM
To: Peters, Matt
Cc: starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>; Qin, Kailun
Subject: Question about patch upstreaming for 1e9a089

Hi Matt,

We’re looking into the patch 1e9a089, which target to solve the issue of “CGTS-2408: bypass policy check when setting attribute to None.”

After investigating this issue, it is found that this issue will only happen for attribute which need to meet below conditions:
(1) the validate rule is: “type: uuid_or_none”
(2) the “enforce_policy” should be set to “True” and the policy needs to be defined in etc/policy.json
(3) the check policy uses “tenant_id” for owner check

The only found attribute which will be impacted by this issue in STX is “wrs-tm:qos” which will be removed later after STX applying upstreaming QOS API. Since no other impacted attributes can be found in upstream (or could you please share with us if you see any other attributes which may be impacted by this issue?), What’s your proposal for upstreaming or Do you think holding on this fix is make sense for now?

Thank much!

Best Regards,
Le, Huifeng

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20181017/2d2775b2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1808 bytes
Desc: image001.png
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20181017/2d2775b2/attachment-0001.png>