glance/doc/source/contributor/refreshing-configs.rst
Doug Hellmann 1c7f556d4f rearrange existing documentation to follow the new layout standard
This change moves existing files, updates a few of the cross-references
and paths, and fixes some formatting. It is not meant to be the final
word on how the main page looks or how the other files are organized,
but it gets everything roughly into shape. If the glance team wants to
make changes, please do those as follow-up patches

This change depends on the spec and on a feature of pbr that allows us
to move where the auto-generated class reference documentation ends up
in the tree.

Depends-On: Ia750cb049c0f53a234ea70ce1f2bbbb7a2aa9454
Depends-On: I2bd5652bb59cbd9c939931ba2e7db1b37d2b30bb
Change-Id: I9dde267793a5913acb5b1ec028cfb66bc5189783
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
2017-06-21 14:15:58 -04:00

2.8 KiB

Guideline On Refreshing Configuration Files Under etc/

During a release cycle many configuration options are changed or updated. The sample configuration files provided in tree (under etc/*) need to be updated using the autogeneration tool as these files are being used in different places. Some examples are devstack gates, downstream packagers shipping with the same (or using defaults from these files), etc. Hence, before we cut a release we need to refresh the configuration files shipped with tree to match the changes done in the source code during the release cycle.

In an ideal world, every review that proposes an addition, removal or update to a configuration option(s) should use the tox tool to refresh only the configuration options(s) that were changed. However, many of the configuration options like those coming from oslo.messaging, oslo_middleware, etc. may have changed in the meantime. So, whenever someone uses the tool to autogenerate the configuration files based on the options in tree, there are more changes than those made just by the author.

We do not recommend the authors to manually edit the autogenerated files so, a reasonable tradeoff is for the authors to include only those files that are affected by their change(s).

$ tox -e genconfig

When To Refresh The Sample Configuration Files

  • Every review that proposes an addition, removal or update to a configuration option(s) should use the tox tool to refresh only the configuration option(s) they have changed.
  • Ideally reviewers should request updates to sample configuration files for every change that attempts to add/delete/modify a configuration option(s) in the code.
  • In some situations however, there may be a bunch of similar changes that are affecting the configuration files. In this case, in order to make the developers' and reviewers' effort easier, we recommend an update to the configuration files in bulk right after all the update changes have been made/merged.

IMPORTANT NOTE: All sample configuration files mush be updated before the milestone-3 (or the final release) of the project.