openstack-manuals/doc/common/tables/swift-rsyncd-container.xml

31 lines
1.3 KiB
XML
Raw Normal View History

<?xml version="1.0" encoding="UTF-8"?>
Make swift config tables the source of truth As discussed on the mailing list, this patch will make the swift configuration tables found in common a source of truth for the helptext. The script that generates them has been updated for this, and will now only add/remove options, update default values, and replace helptext where it does not exist in the tables. Another run of the script was done and tables were updated. Backstory: All projects other than Swift use OpenStack Common for configuration, and define option, default value and help text in the code in a way that it's possible to extract. Since the code is able to act in this way, we can stop maintaining separate instructive lines for configuration options, and instead fix any text problems in the code itself. This both improves the quality of the code and fixes our double maintenance problem. For swift, we needed a different approach. Unfortunately, I think we don't have the ability to treat the code as the definitive source and move all maintenance there. The lack of instruction for every option, and absence of structure precludes this. So I wrote some nasty scraping things (from RST and sample conf file) to seed an initial list of configuration options. My plan from here was to make the 'update' portion of the script treat the textual descriptions in common/tables/swift-*.xml as definitive. The script would still search the swift code to add or remove options, so we could guarantee completeness, and after an initial push to write out proper help text the maintenance becomes far simpler. Change-Id: I2464f5c63cb0da110e1871a09a59380dad9b6b27
2013-09-03 00:39:38 +00:00
<!-- The tool that generated this table lives in the
tools directory of this repository. As it was a one-time
generation, you can edit this file. -->
<para xmlns="http://docbook.org/ns/docbook" version="5.0">
<table rules="all">
<caption>Description of configuration options for <literal>[container]</literal> in <literal>rsyncd.conf-sample</literal></caption>
<col width="50%"/>
<col width="50%"/>
<thead>
<tr>
<th>Configuration option = Default value</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>max connections = 4</td><td>No help text available for this option</td>
Make swift config tables the source of truth As discussed on the mailing list, this patch will make the swift configuration tables found in common a source of truth for the helptext. The script that generates them has been updated for this, and will now only add/remove options, update default values, and replace helptext where it does not exist in the tables. Another run of the script was done and tables were updated. Backstory: All projects other than Swift use OpenStack Common for configuration, and define option, default value and help text in the code in a way that it's possible to extract. Since the code is able to act in this way, we can stop maintaining separate instructive lines for configuration options, and instead fix any text problems in the code itself. This both improves the quality of the code and fixes our double maintenance problem. For swift, we needed a different approach. Unfortunately, I think we don't have the ability to treat the code as the definitive source and move all maintenance there. The lack of instruction for every option, and absence of structure precludes this. So I wrote some nasty scraping things (from RST and sample conf file) to seed an initial list of configuration options. My plan from here was to make the 'update' portion of the script treat the textual descriptions in common/tables/swift-*.xml as definitive. The script would still search the swift code to add or remove options, so we could guarantee completeness, and after an initial push to write out proper help text the maintenance becomes far simpler. Change-Id: I2464f5c63cb0da110e1871a09a59380dad9b6b27
2013-09-03 00:39:38 +00:00
</tr>
<tr>
<td>path = /srv/node</td><td>No help text available for this option</td>
Make swift config tables the source of truth As discussed on the mailing list, this patch will make the swift configuration tables found in common a source of truth for the helptext. The script that generates them has been updated for this, and will now only add/remove options, update default values, and replace helptext where it does not exist in the tables. Another run of the script was done and tables were updated. Backstory: All projects other than Swift use OpenStack Common for configuration, and define option, default value and help text in the code in a way that it's possible to extract. Since the code is able to act in this way, we can stop maintaining separate instructive lines for configuration options, and instead fix any text problems in the code itself. This both improves the quality of the code and fixes our double maintenance problem. For swift, we needed a different approach. Unfortunately, I think we don't have the ability to treat the code as the definitive source and move all maintenance there. The lack of instruction for every option, and absence of structure precludes this. So I wrote some nasty scraping things (from RST and sample conf file) to seed an initial list of configuration options. My plan from here was to make the 'update' portion of the script treat the textual descriptions in common/tables/swift-*.xml as definitive. The script would still search the swift code to add or remove options, so we could guarantee completeness, and after an initial push to write out proper help text the maintenance becomes far simpler. Change-Id: I2464f5c63cb0da110e1871a09a59380dad9b6b27
2013-09-03 00:39:38 +00:00
</tr>
<tr>
<td>read only = false</td><td>No help text available for this option</td>
Make swift config tables the source of truth As discussed on the mailing list, this patch will make the swift configuration tables found in common a source of truth for the helptext. The script that generates them has been updated for this, and will now only add/remove options, update default values, and replace helptext where it does not exist in the tables. Another run of the script was done and tables were updated. Backstory: All projects other than Swift use OpenStack Common for configuration, and define option, default value and help text in the code in a way that it's possible to extract. Since the code is able to act in this way, we can stop maintaining separate instructive lines for configuration options, and instead fix any text problems in the code itself. This both improves the quality of the code and fixes our double maintenance problem. For swift, we needed a different approach. Unfortunately, I think we don't have the ability to treat the code as the definitive source and move all maintenance there. The lack of instruction for every option, and absence of structure precludes this. So I wrote some nasty scraping things (from RST and sample conf file) to seed an initial list of configuration options. My plan from here was to make the 'update' portion of the script treat the textual descriptions in common/tables/swift-*.xml as definitive. The script would still search the swift code to add or remove options, so we could guarantee completeness, and after an initial push to write out proper help text the maintenance becomes far simpler. Change-Id: I2464f5c63cb0da110e1871a09a59380dad9b6b27
2013-09-03 00:39:38 +00:00
</tr>
<tr>
<td>lock file = /var/lock/container.lock</td><td>No help text available for this option</td>
Make swift config tables the source of truth As discussed on the mailing list, this patch will make the swift configuration tables found in common a source of truth for the helptext. The script that generates them has been updated for this, and will now only add/remove options, update default values, and replace helptext where it does not exist in the tables. Another run of the script was done and tables were updated. Backstory: All projects other than Swift use OpenStack Common for configuration, and define option, default value and help text in the code in a way that it's possible to extract. Since the code is able to act in this way, we can stop maintaining separate instructive lines for configuration options, and instead fix any text problems in the code itself. This both improves the quality of the code and fixes our double maintenance problem. For swift, we needed a different approach. Unfortunately, I think we don't have the ability to treat the code as the definitive source and move all maintenance there. The lack of instruction for every option, and absence of structure precludes this. So I wrote some nasty scraping things (from RST and sample conf file) to seed an initial list of configuration options. My plan from here was to make the 'update' portion of the script treat the textual descriptions in common/tables/swift-*.xml as definitive. The script would still search the swift code to add or remove options, so we could guarantee completeness, and after an initial push to write out proper help text the maintenance becomes far simpler. Change-Id: I2464f5c63cb0da110e1871a09a59380dad9b6b27
2013-09-03 00:39:38 +00:00
</tr>
</tbody>
</table>
</para>