Open Stack

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.

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

> 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
the file format actually provided in distro packages.

Thank you,
Takashi Kajinami

On Wed, Apr 29, 2020 at 5:18 AM Thomas Goirand <zigo at 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 at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200430/a0992ed6/attachment-0001.html>