This looks very promising, thank you. One concern I have is that we maintain some of the troubleshooting ability that the hieradata files give us today in the long term.
The hieradata files on overcloud nodes make it convenient to glean facts about the deployed host. They also act as a canary for when the overcloud Heat stacks are out of sync with the deployed hosts.
Once we make the param_config consumable by Ansible or etcd, please keep supportability and troubleshooting in mind. Having local config data in a convenient place on the deployed host is important.
You made very good points and I think we'll maintain an optional puppet step where our operators can apply any Hiera like before; at least until we think our operators have switched to the new interface at some point.
For debugging, we could think of the same kind of usage, where you have your custom-params.yaml like :
---
glance_api_config:
DEFAULT:
enable_v2_api: true
log_dir: /var/log/glance
We would merge the hashes and lay down the config (with some hierarchy like before with Hiera datafiles).
Also a note on etcd; even if the data would be consumed from etcd by services (currently not supported by oslo-config AFIK), the data would be available in config-download when generating the playbooks & data, so we could make it so you can modify the data and run the playbooks to change any config.
Thanks for your feedback,