edd5bf9e17
TrivialFix Change-Id: Idb940fd023f3d8d449ba1e35b5a2afdc164722e4
63 lines
2.8 KiB
ReStructuredText
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.
|