2013-08-21 12:30:47 +10: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 10:39:38 +10: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 12:30:47 +10:00
|
|
|
<para xmlns="http://docbook.org/ns/docbook" version="5.0">
|
|
|
|
|
<table rules="all">
|
|
|
|
|
<caption>Description of configuration options for <literal>[swift-constraints]</literal> in <literal>swift.conf-sample</literal></caption>
|
|
|
|
|
<col width="50%"/>
|
|
|
|
|
<col width="50%"/>
|
|
|
|
|
<thead>
|
|
|
|
|
<tr>
|
2014-01-07 16:01:52 -05:00
|
|
|
<th>Configuration option = Default value</th>
|
|
|
|
|
<th>Description</th>
|
2013-08-21 12:30:47 +10:00
|
|
|
</tr>
|
|
|
|
|
</thead>
|
|
|
|
|
<tbody>
|
|
|
|
|
<tr>
|
2014-01-07 16:01:52 -05:00
|
|
|
<td>max_file_size = 5368709122</td>
|
2013-09-19 21:27:56 +02:00
|
|
|
<td>The largest normal object that can be
|
|
|
|
|
saved in the cluster. This is also the
|
|
|
|
|
limit on the size of each segment of a
|
|
|
|
|
large object when using the large object
|
|
|
|
|
manifest support. This value is set in
|
|
|
|
|
bytes. Setting it to lower than 1MiB will
|
|
|
|
|
cause some tests to fail. It is STRONGLY
|
|
|
|
|
recommended to leave this value at the
|
|
|
|
|
default (5 * 2**30 + 2).</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 10:39:38 +10:00
|
|
|
</tr>
|
2013-08-21 12:30:47 +10:00
|
|
|
<tr>
|
2014-01-07 16:01:52 -05:00
|
|
|
<td>max_meta_name_length = 128</td>
|
2013-09-19 21:27:56 +02:00
|
|
|
<td>The maximum number of bytes in the utf8
|
|
|
|
|
encoding of the name portion of a metadata
|
|
|
|
|
header.</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 10:39:38 +10:00
|
|
|
</tr>
|
2013-08-21 12:30:47 +10:00
|
|
|
<tr>
|
2014-01-07 16:01:52 -05:00
|
|
|
<td>max_meta_value_length = 256</td>
|
2013-09-19 21:27:56 +02:00
|
|
|
<td>The max number of bytes in the utf8
|
|
|
|
|
encoding of a metadata value.</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 10:39:38 +10:00
|
|
|
</tr>
|
2013-08-21 12:30:47 +10:00
|
|
|
<tr>
|
2014-01-07 16:01:52 -05:00
|
|
|
<td>max_meta_count = 90</td>
|
2013-09-19 21:27:56 +02:00
|
|
|
<td>The maximum number of metadata keys that can
|
|
|
|
|
be stored on a single account, container,
|
|
|
|
|
or 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 10:39:38 +10:00
|
|
|
</tr>
|
2013-08-21 12:30:47 +10:00
|
|
|
<tr>
|
2014-01-07 16:01:52 -05:00
|
|
|
<td>max_meta_overall_size = 4096</td>
|
2013-09-19 21:27:56 +02:00
|
|
|
<td>The maximum number of bytes in the utf8
|
|
|
|
|
encoding of the metadata (keys +
|
|
|
|
|
values).</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 10:39:38 +10:00
|
|
|
</tr>
|
2013-08-21 12:30:47 +10:00
|
|
|
<tr>
|
2014-01-07 16:01:52 -05:00
|
|
|
<td>max_header_size = 8192</td>
|
2013-09-19 21:27:56 +02:00
|
|
|
<td>The maximum number of bytes in the utf8
|
|
|
|
|
encoding of each header.</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 10:39:38 +10:00
|
|
|
</tr>
|
2013-08-21 12:30:47 +10:00
|
|
|
<tr>
|
2014-01-07 16:01:52 -05:00
|
|
|
<td>max_object_name_length = 1024</td>
|
2013-09-19 21:27:56 +02:00
|
|
|
<td>The maximum number of bytes in the utf8
|
|
|
|
|
encoding of an object name.</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 10:39:38 +10:00
|
|
|
</tr>
|
2013-08-21 12:30:47 +10:00
|
|
|
<tr>
|
2014-01-07 16:01:52 -05:00
|
|
|
<td>container_listing_limit = 10000</td>
|
2013-09-19 21:27:56 +02:00
|
|
|
<td>The default (and maximum) number of items
|
|
|
|
|
returned for a container listing
|
|
|
|
|
request.</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 10:39:38 +10:00
|
|
|
</tr>
|
2013-08-21 12:30:47 +10:00
|
|
|
<tr>
|
2014-01-07 16:01:52 -05:00
|
|
|
<td>account_listing_limit = 10000</td>
|
2013-09-19 21:27:56 +02:00
|
|
|
<td>The default (and maximum) number of items
|
|
|
|
|
returned for an account listing request.</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 10:39:38 +10:00
|
|
|
</tr>
|
2013-08-21 12:30:47 +10:00
|
|
|
<tr>
|
2014-01-07 16:01:52 -05:00
|
|
|
<td>max_account_name_length = 256</td>
|
2013-09-19 21:27:56 +02:00
|
|
|
<td>The maximum number of bytes in the utf8
|
|
|
|
|
encoding of an account name.</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 10:39:38 +10:00
|
|
|
</tr>
|
2013-08-21 12:30:47 +10:00
|
|
|
<tr>
|
2014-01-07 16:01:52 -05:00
|
|
|
<td>max_container_name_length = 256</td>
|
2013-09-19 21:27:56 +02:00
|
|
|
<td>The maximum number of bytes in the utf8
|
|
|
|
|
encoding of a container name.</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 10:39:38 +10:00
|
|
|
</tr>
|
2013-08-21 12:30:47 +10:00
|
|
|
</tbody>
|
|
|
|
|
</table>
|
2013-09-19 21:27:56 +02:00
|
|
|
</para>
|