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-wallab... 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