2013-08-21 02:30:47 +00:00
<?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. -->
2013-08-21 02:30:47 +00:00
<para xmlns= "http://docbook.org/ns/docbook" version= "5.0" >
<table rules= "all" >
<caption > Description of configuration options for <literal > [DEFAULT]</literal> in <literal > account-server.conf-sample</literal> </caption>
<col width= "50%" />
<col width= "50%" />
<thead >
<tr >
<td > Configuration option=Default value</td>
<td > Description</td>
</tr>
</thead>
<tbody >
<tr >
<td > bind_ip=0.0.0.0</td> <td > IP Address for server to bind to</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>
2013-08-21 02:30:47 +00:00
<tr >
<td > bind_port=6002</td> <td > Port for server to bind to</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>
2013-08-21 02:30:47 +00:00
<tr >
<td > bind_timeout=30</td> <td > Seconds to attempt bind before giving up</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>
2013-08-21 02:30:47 +00:00
<tr >
<td > backlog=4096</td> <td > Maximum number of allowed pending TCP connections</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>
2013-08-21 02:30:47 +00:00
<tr >
<td > user=swift</td> <td > User to run as</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>
2013-08-21 02:30:47 +00:00
<tr >
<td > swift_dir=/etc/swift</td> <td > Swift configuration directory</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>
2013-08-21 02:30:47 +00:00
<tr >
<td > devices=/srv/node</td> <td > Parent directory of where devices are mounted</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>
2013-08-21 02:30:47 +00:00
<tr >
<td > mount_check=true</td> <td > Whether or not check if the devices are mounted to prevent accidentally writing to the root device</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>
2013-08-21 02:30:47 +00:00
<tr >
<td > disable_fallocate=false</td> <td > Disable "fast fail" fallocate checks if the underlying filesystem does not support it.</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 > workers=auto</td> <td > a much higher value, one can reduce the impact of slow file system operations in one request from negatively impacting other requests.</td>
</tr>
<tr >
<td > max_clients=1024</td> <td > Maximum number of clients one worker can process simultaneously
Lowering the number of clients handled per worker, and raising the
number of workers can lessen the impact that a CPU intensive, or
blocking, request can have on other requests served by the same
worker. If the maximum number of clients is set to one, then a given worker
will not perform another call while processing, allowing
other workers a chance to process it.
</td>
</tr>
2013-08-21 02:30:47 +00:00
<tr >
<td > log_name=swift</td> <td > Label used when logging</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>
2013-08-21 02:30:47 +00:00
<tr >
<td > log_facility=LOG_LOCAL0</td> <td > Syslog log facility</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>
2013-08-21 02:30:47 +00:00
<tr >
<td > log_level=INFO</td> <td > Logging level</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>
2013-08-21 02:30:47 +00:00
<tr >
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
<td > log_address=/dev/log</td> <td > Location where syslog sends the logs to</td>
</tr>
2013-08-21 02:30:47 +00:00
<tr >
<td > log_custom_handlers=</td> <td > Comma-separated list of functions to call to setup custom log handlers.</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>
2013-08-21 02:30:47 +00:00
<tr >
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
<td > log_udp_host=</td> <td > If not set, the UDB receiver for syslog is disabled.</td>
</tr>
2013-08-21 02:30:47 +00:00
<tr >
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
<td > log_udp_port=514</td> <td > Port value for UDB receiver, if enabled.</td>
</tr>
2013-08-21 02:30:47 +00:00
<tr >
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
<td > log_statsd_host=localhost</td> <td > If not set, the StatsD feature is disabled.</td>
</tr>
2013-08-21 02:30:47 +00:00
<tr >
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
<td > log_statsd_port=8125</td> <td > Port value for the StatsD server.</td>
</tr>
2013-08-21 02:30:47 +00:00
<tr >
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
<td > log_statsd_default_sample_rate=1.0</td> <td > Defines the probability of sending a sample for any given event or
timing measurement.</td>
</tr>
2013-08-21 02:30:47 +00:00
<tr >
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
<td > log_statsd_sample_rate_factor=1.0</td> <td > Not recommended to set this to a value less than 1.0, if frequency
of logging is too high, tune the
log_statsd_default_sample_rate instead.</td>
</tr>
2013-08-21 02:30:47 +00:00
<tr >
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
<td > log_statsd_metric_prefix=</td> <td > Value will be prepended to every metric sent to the StatsD server.</td>
</tr>
2013-08-21 02:30:47 +00:00
<tr >
<td > db_preallocation=off</td> <td > If you don't mind the extra disk space usage in overhead, you can turn this on to preallocate disk space with SQLite databases to decrease fragmentation. underlying filesystem does not support it. to setup custom log handlers. bytes you'd like fallocate to reserve, whether there is space for the given file size or not. This is useful for systems that behave badly when they completely run out of space; you can make the services pretend they're out of space early. server. For most cases, this should be `egg:swift#account`. replication passes account can be reclaimed</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>
2013-08-21 02:30:47 +00:00
<tr >
<td > eventlet_debug=false</td> <td > If true, turn on debug logging for eventlet</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>
2013-08-21 02:30:47 +00:00
<tr >
<td > fallocate_reserve=0</td> <td > You can set fallocate_reserve to the number of bytes you'd like fallocate to reserve, whether there is space for the given file size or not. This is useful for systems that behave badly when they completely run out of space; you can make the services pretend they're out of space early. server. For most cases, this should be `egg:swift#object`.</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>
2013-08-21 02:30:47 +00:00
</tbody>
</table>
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
</para>