Due to COVID-19 pandemic, OpenStack PTG for Wallaby development planning and discussions are held virtually from Oct 26 – 30th, 2020. Overall we had a good discussion and another successful virtual PTG though most of us missed the face to face interaction. This blog covers the policy popup (consistent RBAC) discussion that happened in the Forum and Monday and Tuesday PTG.
Progress of consistent RBAC:
- Three projects completed till now – Keystone, Nova and, Cyborg
- One in progress – Barbican
- Planning in Wallaby – Neutron, Manila
We discussed the current and possible future challenges while migrating to the new policy. policy file in JSON format is one know and we talked about a current workaround and long term plan.
Deprecation warnings are still an issue and a lot of warnings are logged. This is logged as a nova bug. Also, the HTML version of the policy doc does not have the deprecation rule and reason. Example: https://docs.openstack.org/nova/latest/configuration/policy.html We need to add it in these docs too.
A clear step by step document about how to use system scope in cloud.yaml as well as in general with all migration steps are much needed.
We also asked if any deployment is migrated to new policy but there is none yet.
We carried the Forum sessions discussion in PTG with few extra topics.
Migrate Default Policy Format from JSON to YAML (All projects)
We talked about it and decided that it will be great to do this in advance before projects start moving towards the new policy. and having this as a community goal in wallaby will help this effort to move faster. I have proposed this as a goal in TC PTG and it was agreed to select it for wallaby (Goal proposal) We also need to update devstack for the neutron policy file which is policy.json.
Deprecation warning on-demand based on config option?
There is no best solution for deprecation warnings when it is a lot in case of new policy work. We cannot stop logging warnings completely. We discussed an option to provide a config option to disable the warnings (enable by default) and only for default value change, not the policy name change. The policy name change is a little critical even in policy overridden case also that is why we should not make it switchable. This way operators can disable warnings after seeing it for the first time and if it is too noisy.
New policy in Horizon
It is challenging to adopt new policy in Horizon when some projects have new policies and some not. We left this for now and will continue brainstorming once we do some investigation on the usage of system token for new policy and old one. For now, amotoki proposed a workaround to keep the policy file with the deprecated rule as the overridden rules. –
What are the expectations from project teams?
In the end, we discussed what all things to be targeted as part of new policy work and what all as a separate effort. Below is the list and I will be documenting it on wiki.
- Things to do as part of new policy effort:
- Migrating JSON to YAML (in advance though)
- Policy Tests coverage
- System scoped administrator policy support and “reader” role support
- upgrade-check support when changing the default policy
- As separate effort:
- Remove hard-coded admin checks in the API/DB/”Views”
- Standardizing policy names (depends on projects)