diff --git a/doc/source/admin_guide.rst b/doc/source/admin_guide.rst index a39d164534..99cd9c2446 100644 --- a/doc/source/admin_guide.rst +++ b/doc/source/admin_guide.rst @@ -209,7 +209,7 @@ Debugging Tips and Tools When a request is made to Swift, it is given a unique transaction id. This id should be in every log line that has to do with that request. This can -be usefult when looking at all the services that are hit by a single request. +be useful when looking at all the services that are hit by a single request. If you need to know where a specific account, container or object is in the cluster, `swift-get-nodes` will show the location where each replica should be. diff --git a/doc/source/development_auth.rst b/doc/source/development_auth.rst index afbe776bab..446a10a157 100644 --- a/doc/source/development_auth.rst +++ b/doc/source/development_auth.rst @@ -39,8 +39,8 @@ will be omitted. It is highly recommended that authentication server implementers prefix their tokens and Swift storage accounts they create with a configurable reseller -prefix (`AUTH_` by default with the included DevAuth). This prefix will allow -deconflicting with other authentication servers that might be using the same +prefix (`AUTH_` by default with the included DevAuth). This prefix will avoid +conflicts with other authentication servers that might be using the same Swift cluster. Otherwise, the Swift cluster will have to try all the resellers until one validates a token or all fail. @@ -67,7 +67,7 @@ Example Authentication with DevAuth: Authorization is performed through callbacks by the Swift Proxy server to the WSGI environment's swift.authorize value, if one is set. The swift.authorize -value should simply be a function that takes a webob.Request as an argument and +value should simply be a function that takes a WebOb. Request as an argument and returns None if access is granted or returns a callable(environ, start_response) if access is denied. This callable is a standard WSGI callable. Generally, you should return 403 Forbidden for requests by an authenticated @@ -131,7 +131,7 @@ then swift.authorize will be called once more. These are called delay_denial requests and currently include container read requests and object read and write requests. For these requests, the read or write access control string (X-Container-Read and X-Container-Write) will be fetched and set as the 'acl' -attribute in the webob.Request passed to swift.authorize. +attribute in the WebOb.Request passed to swift.authorize. The delay_denial procedures allow skipping possibly expensive access control string retrievals for requests that can be approved without that information, @@ -179,7 +179,7 @@ The access control string has a standard format included with Swift, though this can be overridden if desired. The standard format can be parsed with swift.common.middleware.acl.parse_acl which converts the string into two arrays of strings: (referrers, groups). The referrers allow comparing the request's -Referer header to control access. The groups allow comparing the +Referrer header to control access. The groups allow comparing the request.remote_user (or other sources of group information) to control access. Checking referrer access can be accomplished by using the swift.common.middleware.acl.referrer_allowed function. Checking group access is diff --git a/doc/source/overview_architecture.rst b/doc/source/overview_architecture.rst index 9a69f746a7..7cd56a8c7c 100644 --- a/doc/source/overview_architecture.rst +++ b/doc/source/overview_architecture.rst @@ -18,7 +18,7 @@ example, if a server is unavailable for an object PUT, it will ask the ring for a handoff server and route there instead. When objects are streamed to or from an object server, they are streamed -directly through the proxy server to of from the user -- the proxy server +directly through the proxy server to or from the user -- the proxy server does not spool them. -------- @@ -32,7 +32,7 @@ container, or account, they need to interact with the appropriate ring to determine its location in the cluster. The Ring maintains this mapping using zones, devices, partitions, and replicas. -Each partition in the ring is replicated, by default, 3 times accross the +Each partition in the ring is replicated, by default, 3 times across the cluster, and the locations for a partition are stored in the mapping maintained by the ring. The ring is also responsible for determining which devices are used for handoff in failure scenarios. diff --git a/doc/source/overview_reaper.rst b/doc/source/overview_reaper.rst index 020085dbc2..7959c2c557 100644 --- a/doc/source/overview_reaper.rst +++ b/doc/source/overview_reaper.rst @@ -28,7 +28,7 @@ delete times out, the container won't be able to be deleted later and therefore the account won't be deleted either). The overall process continues even on a failure so that it doesn't get hung up reclaiming cluster space because of one troublesome spot. The account reaper will keep trying to delete an account -until it evetually becomes empty, at which point the database reclaim process +until it eventually becomes empty, at which point the database reclaim process within the db_replicator will eventually remove the database files. -------