openstack/swift
Code Issues Proposed changes

Remove Erasure Coding beta status from docs

Browse Source 
This removes notes stating support for Erasure coding as beta. Questions
regarding the stability of EC are coming up regularly, and are often referring
to the docs that state EC as still in beta.

Besides this, a note marking statsd support as beta has been removed as well.

Change-Id: If4fb6a5c4cb741d42953db3cee8cb17a1d774e15
This commit is contained in:
Christian Schwede 2016-03-04 09:33:17 +00:00
parent 5930d74d81
commit 043fbca6d0
4 changed files with 6 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
doc/source/admin_guide.rst
View File

@ -684,8 +684,7 @@ of async_pendings in real-time, but will not tell you the current number of
async_pending container updates on disk at any point in time.
Note also that the set of metrics collected, their names, and their semantics
are not locked down and will change over time. StatsD logging is currently in
a "beta" stage and will continue to evolve.
are not locked down and will change over time.
Metrics for `account-auditor`:

10
doc/source/overview_erasure_code.rst
View File

@ -182,17 +182,13 @@ similar to that of replication with a few notable exceptions:
Performance Considerations
--------------------------
Efforts are underway to characterize performance of various Erasure Code
schemes. One of the main goals of the beta release is to perform this
characterization and encourage others to do so and provide meaningful feedback
to the development community. There are many factors that will affect
performance of EC so it is vital that we have multiple characterization
activities happening.
In general, EC has different performance characteristics than replicated data.
EC requires substantially more CPU to read and write data, and is more suited
for larger objects that are not frequently accessed (eg backups).
Operators are encouraged to characterize the performance of various EC schemes
and share their observations with the developer community.
----------------------------
Using an Erasure Code Policy
----------------------------

3
doc/source/overview_policies.rst
View File

@ -37,8 +37,7 @@ There are many reasons why this might be desirable:
.. note::
Today, Swift supports two different policy types: Replication and Erasure
Code. Erasure Code policy is currently a beta release and should not be
used in a Production cluster. See :doc:`overview_erasure_code` for details.
Code. See :doc:`overview_erasure_code` for details.
Also note that Diskfile refers to backend object storage plug-in
architecture. See :doc:`development_ondisk_backends` for details.

3
etc/swift.conf-sample
View File

@ -51,8 +51,7 @@ aliases = yellow, orange
#policy_type = replication
# The following declares a storage policy of type 'erasure_coding' which uses
# Erasure Coding for data reliability. The 'erasure_coding' storage policy in
# Swift is available as a "beta". Please refer to Swift documentation for
# Erasure Coding for data reliability. Please refer to Swift documentation for
# details on how the 'erasure_coding' storage policy is implemented.
#
# Swift uses PyECLib, a Python Erasure coding API library, for encode/decode