So, my proposal is the following: before the final release of OpenStack, I will modify all Debian OpenStack packages to generate (and package) both policy.json and policy.yaml. Then puppet-openstack can switch over to the .yaml file, and uncomment only the parts that the operator sees as relevant. What I think is important from a puppet perspective is that we should handle transition correctly. I mean, we should not use yaml format until the distro packaging actually
I also would like to add a policy.d folder by default in each package, where operators can override stuff. Just having the folder will be a sign to operators that they are invited to write stuff in there, and that it will not be overwritten by a package upgrade. This sounds like a really good idea. It seems like oslo.policy doesn't care about the actual format of files under policy.d, so if we only touch files there, I guess that we can start with a yaml file, without considering
Hi Thomas, Thanks for bringing up this interesting and important topic. I agree with you suggestions, because IIUC policy.yaml is a generally preferred option, and I personally prefer to use yaml instead of json because of its readability. Unfortunately I've never touched packaging stuff, so I can't give any feedback from a packaging perspective at the moment. I'll leave this for other teams like ubuntu packaging team or rdo packaging team. However let me put some of my thoughts about the described details from a puppet perspective. provides a yaml file. My current idea is to implement a parameter like nova::params::policy_format, which is (or whose default is) decided based on os family and distro, so that we use the correct format according to transition status. the file format actually provided in distro packages. Thank you, Takashi Kajinami On Wed, Apr 29, 2020 at 5:18 AM Thomas Goirand <zigo@debian.org> wrote:
Hi team!
In the light of the discussion that recently happened in #openstack-nova, it looks like switching from a .json file to a .yaml file is what we should do. Indeed, the file generated in .json format, if used pristine with the nova.conf and without enforcing scope, makes a nova-api service that simply doesn't work.
Please read https://bugs.launchpad.net/nova/+bug/1875418 for more insights.
The issue is that both packages are generating a .json (at least in Debian and Ubuntu) and puppet expect a policy.json, not a policy.yaml.
With the policy.yaml, we don't have the same problem as by default, all policies are commented out. Operators just need to uncomment to activate.
So, my proposal is the following: before the final release of OpenStack, I will modify all Debian OpenStack packages to generate (and package) both policy.json and policy.yaml. Then puppet-openstack can switch over to the .yaml file, and uncomment only the parts that the operator sees as relevant.
I also would like to add a policy.d folder by default in each package, where operators can override stuff. Just having the folder will be a sign to operators that they are invited to write stuff in there, and that it will not be overwritten by a package upgrade.
Then what I would like to do, is get puppet-openstack to only write there, for example in /etc/nova/policy.d/my-custom-policy.yaml. The file in /etc/nova/policy.yaml will be marked as "CONFFILE" in Debian, meaning that dpkg will prompt for changes on upgrades, while what's in the policy.d will remain.
Last, I do believe that the yaml files are a way more easy to handle with puppet than the .json counterpart. Indeed, we could use something like the .ini management thing, with the : (Semicolumn) sign replacing the = (equal) sign. Moreover, the .yaml files contain comments which the .json files are lacking, making it auto-documented for operators.
The only reason why I didn't use .yaml files earlier in the Debian packages was that, somehow, loading them with the API didn't work. I confirm that now it looks like working (though I'd have to test if changing a value is taken into account, I didn't do that yet).
Your thoughts everyone?
Cheers,
Thomas Goirand (zigo)
-- ---------- Takashi Kajinami Senior Software Maintenance Engineer Customer Experience and Engagement Red Hat e-mail: tkajinam@redhat.com