Open Stack

Hello Everyone,

'policy' popup team hosted 2 sessions in Wallaby Virtual PTG to discuss the progress and next steps.

Forum:
=====
https://etherpad.opendev.org/p/consistent-and-secure-default-policies-wallaby

Progress:
* 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 bug in
nova[1]. 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.

PTG:
====

https://etherpad.opendev.org/p/policy-popup-wallaby-ptg

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: https://review.opendev.org/#/c/759881/2

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.
- https://review.opendev.org/#/c/750134/

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)

[1] https://bugs.launchpad.net/nova/+bug/1900451

-gmann