glance/doc/source/contributing/refreshing-configs.rst
Nikhil Komawar edd5bf9e17 Dev-docs: command in code block for refresh config
TrivialFix

Change-Id: Idb940fd023f3d8d449ba1e35b5a2afdc164722e4
2016-09-07 16:22:32 -04:00

63 lines
2.8 KiB
ReStructuredText

..
Copyright 2016-present OpenStack Foundation
All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
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).
.. code-block:: bash
$ 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.