Skip to content

Commit 069bedd

Browse files
Jenkinsopenstack-gerrit
authored andcommitted
Merge "Fixed grammar and improve docs."
2 parents 9fe0a1c + 92fbf44 commit 069bedd

File tree

11 files changed

+79
-38
lines changed

11 files changed

+79
-38
lines changed

AUTHORS

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -34,6 +34,7 @@ Soren Hansen ([email protected])
3434
Derek Higgins ([email protected])
3535
Florian Hines ([email protected])
3636
Paul Jimenez ([email protected])
37+
Paul McMillan ([email protected])
3738
Brian K. Jones ([email protected])
3839
Morita Kazutaka ([email protected])
3940

doc/source/admin_guide.rst

Lines changed: 51 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,11 @@ Administrator's Guide
66
Managing the Rings
77
------------------
88

9-
You need to build the storage rings on the proxy server node, and distribute them to all the servers in the cluster. Storage rings contain information about all the Swift storage partitions and how they are distributed between the different nodes and disks. For more information see :doc:`overview_ring`.
9+
You need to build the storage rings on the proxy server node, and
10+
distribute them to all the servers in the cluster. Storage rings
11+
contain information about all the Swift storage partitions and how
12+
they are distributed between the different nodes and disks. For more
13+
information see :doc:`overview_ring`.
1014

1115
Removing a device from the ring::
1216

@@ -37,7 +41,8 @@ Scripting Ring Creation
3741
-----------------------
3842
You can create scripts to create the account and container rings and rebalance. Here's an example script for the Account ring. Use similar commands to create a make-container-ring.sh script on the proxy server node.
3943

40-
1. Create a script file called make-account-ring.sh on the proxy server node with the following content::
44+
1. Create a script file called make-account-ring.sh on the proxy
45+
server node with the following content::
4146

4247
#!/bin/bash
4348
cd /etc/swift
@@ -47,14 +52,25 @@ You can create scripts to create the account and container rings and rebalance.
4752
swift-ring-builder account.builder add z2-<account-server-2>:6002/sdb1 1
4853
swift-ring-builder account.builder rebalance
4954

50-
You need to replace the values of <account-server-1>, <account-server-2>, etc. with the IP addresses of the account servers used in your setup. You can have as many account servers as you need. All account servers are assumed to be listening on port 6002, and have a storage device called "sdb1" (this is a directory name created under /drives when we setup the account server). The "z1", "z2", etc. designate zones, and you can choose whether you put devices in the same or different zones.
55+
You need to replace the values of <account-server-1>,
56+
<account-server-2>, etc. with the IP addresses of the account
57+
servers used in your setup. You can have as many account servers as
58+
you need. All account servers are assumed to be listening on port
59+
6002, and have a storage device called "sdb1" (this is a directory
60+
name created under /drives when we setup the account server). The
61+
"z1", "z2", etc. designate zones, and you can choose whether you
62+
put devices in the same or different zones.
5163

5264
2. Make the script file executable and run it to create the account ring file::
5365

5466
chmod +x make-account-ring.sh
5567
sudo ./make-account-ring.sh
5668

57-
3. Copy the resulting ring file /etc/swift/account.ring.gz to all the account server nodes in your Swift environment, and put them in the /etc/swift directory on these nodes. Make sure that every time you change the account ring configuration, you copy the resulting ring file to all the account nodes.
69+
3. Copy the resulting ring file /etc/swift/account.ring.gz to all the
70+
account server nodes in your Swift environment, and put them in the
71+
/etc/swift directory on these nodes. Make sure that every time you
72+
change the account ring configuration, you copy the resulting ring
73+
file to all the account nodes.
5874

5975
-----------------------
6076
Handling System Updates
@@ -385,11 +401,26 @@ Swift Orphans
385401

386402
Swift Orphans are processes left over after a reload of a Swift server.
387403

388-
For example, when upgrading a proxy server you would probaby finish with a `swift-init proxy-server reload` or `/etc/init.d/swift-proxy reload`. This kills the parent proxy server process and leaves the child processes running to finish processing whatever requests they might be handling at the time. It then starts up a new parent proxy server process and its children to handle new incoming requests. This allows zero-downtime upgrades with no impact to existing requests.
389-
390-
The orphaned child processes may take a while to exit, depending on the length of the requests they were handling. However, sometimes an old process can be hung up due to some bug or hardware issue. In these cases, these orphaned processes will hang around forever. `swift-orphans` can be used to find and kill these orphans.
391-
392-
`swift-orphans` with no arguments will just list the orphans it finds that were started more than 24 hours ago. You shouldn't really check for orphans until 24 hours after you perform a reload, as some requests can take a long time to process. `swift-orphans -k TERM` will send the SIG_TERM signal to the orphans processes, or you can `kill -TERM` the pids yourself if you prefer.
404+
For example, when upgrading a proxy server you would probaby finish
405+
with a `swift-init proxy-server reload` or `/etc/init.d/swift-proxy
406+
reload`. This kills the parent proxy server process and leaves the
407+
child processes running to finish processing whatever requests they
408+
might be handling at the time. It then starts up a new parent proxy
409+
server process and its children to handle new incoming requests. This
410+
allows zero-downtime upgrades with no impact to existing requests.
411+
412+
The orphaned child processes may take a while to exit, depending on
413+
the length of the requests they were handling. However, sometimes an
414+
old process can be hung up due to some bug or hardware issue. In these
415+
cases, these orphaned processes will hang around
416+
forever. `swift-orphans` can be used to find and kill these orphans.
417+
418+
`swift-orphans` with no arguments will just list the orphans it finds
419+
that were started more than 24 hours ago. You shouldn't really check
420+
for orphans until 24 hours after you perform a reload, as some
421+
requests can take a long time to process. `swift-orphans -k TERM` will
422+
send the SIG_TERM signal to the orphans processes, or you can `kill
423+
-TERM` the pids yourself if you prefer.
393424

394425
You can run `swift-orphans --help` for more options.
395426

@@ -398,6 +429,14 @@ You can run `swift-orphans --help` for more options.
398429
Swift Oldies
399430
------------
400431

401-
Swift Oldies are processes that have just been around for a long time. There's nothing necessarily wrong with this, but it might indicate a hung process if you regularly upgrade and reload/restart services. You might have so many servers that you don't notice when a reload/restart fails, `swift-oldies` can help with this.
402-
403-
For example, if you upgraded and reloaded/restarted everything 2 days ago, and you've already cleaned up any orphans with `swift-orphans`, you can run `swift-oldies -a 48` to find any Swift processes still around that were started more than 2 days ago and then investigate them accordingly.
432+
Swift Oldies are processes that have just been around for a long
433+
time. There's nothing necessarily wrong with this, but it might
434+
indicate a hung process if you regularly upgrade and reload/restart
435+
services. You might have so many servers that you don't notice when a
436+
reload/restart fails, `swift-oldies` can help with this.
437+
438+
For example, if you upgraded and reloaded/restarted everything 2 days
439+
ago, and you've already cleaned up any orphans with `swift-orphans`,
440+
you can run `swift-oldies -a 48` to find any Swift processes still
441+
around that were started more than 2 days ago and then investigate
442+
them accordingly.

doc/source/deployment_guide.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -172,11 +172,11 @@ The resulting configuration that myapp receives is::
172172
So, `name1` got the global value which is fine since it's only in the `DEFAULT`
173173
section anyway.
174174

175-
`name2` got the global value from `DEFAULT` even though it's seemingly
175+
`name2` got the global value from `DEFAULT` even though it appears to be
176176
overridden in the `app:myapp` subsection. This is just the unfortunate way
177177
paste.deploy works (at least at the time of this writing.)
178178

179-
`name3` got the local value from the `app:myapp` subsection because it using
179+
`name3` got the local value from the `app:myapp` subsection because it is using
180180
the special paste.deploy syntax of ``set option_name = value``. So, if you want
181181
a default value for most app/filters but want to overridde it in one
182182
subsection, this is how you do it.

doc/source/development_auth.rst

Lines changed: 5 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -218,10 +218,11 @@ only allow GETs after a referrer check and any requests after a group check::
218218
return Authorization(app, conf)
219219
return auth_filter
220220

221-
The access control strings are set with PUTs and POSTs to containers with the
222-
X-Container-Read and X-Container-Write headers. Swift allows these strings to
223-
be set to any value, though it's very useful to validate the strings meet the
224-
desired format and return a useful error to the user if they don't.
221+
The access control strings are set with PUTs and POSTs to containers
222+
with the X-Container-Read and X-Container-Write headers. Swift allows
223+
these strings to be set to any value, though it's very useful to
224+
validate that the strings meet the desired format and return a useful
225+
error to the user if they don't.
225226

226227
To support this validation, the Swift Proxy application will call the WSGI
227228
environment's swift.clean_acl callback whenever one of these headers is to be

doc/source/overview_large_objects.rst

Lines changed: 11 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -17,9 +17,9 @@ with the possibility of parallel uploads of the segments.
1717
Using ``swift`` for Segmented Objects
1818
-------------------------------------
1919

20-
The quickest way to try out this feature is use the included ``swift`` Swift Tool.
21-
You can use the ``-S`` option to specify the segment size to use when splitting
22-
a large file. For example::
20+
The quickest way to try out this feature is use the included ``swift``
21+
Swift Tool. You can use the ``-S`` option to specify the segment size
22+
to use when splitting a large file. For example::
2323

2424
swift upload test_container -S 1073741824 large_file
2525

@@ -31,10 +31,10 @@ So now, the following ``swift`` command would download the entire large object::
3131

3232
swift download test_container large_file
3333

34-
``swift`` uses a strict convention for its segmented object support. In the above
35-
example it will upload all the segments into a second container named
36-
test_container_segments. These segments will have names like
37-
large_file/1290206778.25/21474836480/00000000,
34+
``swift`` uses a strict convention for its segmented object
35+
support. In the above example it will upload all the segments into a
36+
second container named test_container_segments. These segments will
37+
have names like large_file/1290206778.25/21474836480/00000000,
3838
large_file/1290206778.25/21474836480/00000001, etc.
3939

4040
The main benefit for using a separate container is that the main container
@@ -52,10 +52,10 @@ multiple versions of the same large object available.
5252
Direct API
5353
----------
5454

55-
You can also work with the segments and manifests directly with HTTP requests
56-
instead of having ``swift`` do that for you. You can just upload the segments like
57-
you would any other object and the manifest is just a zero-byte file with an
58-
extra ``X-Object-Manifest`` header.
55+
You can also work with the segments and manifests directly with HTTP
56+
requests instead of having ``swift`` do that for you. You can just
57+
upload the segments like you would any other object and the manifest
58+
is just a zero-byte file with an extra ``X-Object-Manifest`` header.
5959

6060
All the object segments need to be in the same container, have a common object
6161
name prefix, and their names sort in the order they should be concatenated.

swift/common/manager.py

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -539,7 +539,7 @@ def wait(self, **kwargs):
539539
"""
540540
status = 0
541541
for proc in self.procs:
542-
# wait for process to close it's stdout
542+
# wait for process to close its stdout
543543
output = proc.stdout.read()
544544
if output:
545545
print output

swift/common/middleware/cname_lookup.py

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -44,7 +44,7 @@
4444

4545
def lookup_cname(domain): # pragma: no cover
4646
"""
47-
Given a domain, returns it's DNS CNAME mapping and DNS ttl.
47+
Given a domain, returns its DNS CNAME mapping and DNS ttl.
4848
4949
:param domain: domain to query on
5050
:returns: (ttl, result)

swift/common/middleware/formpost.py

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -64,7 +64,7 @@
6464
desired.
6565
6666
The expires attribute is the Unix timestamp before which the form
67-
must be submitted before it's invalidated.
67+
must be submitted before it is invalidated.
6868
6969
The signature attribute is the HMAC-SHA1 signature of the form. Here is
7070
sample code for computing the signature::

swift/common/ring/builder.py

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -59,7 +59,7 @@ def __init__(self, part_power, replicas, min_part_hours):
5959
# _last_part_moves is a 2**23 array of unsigned bytes representing the
6060
# number of hours since a given partition was last moved. This is used
6161
# to guarantee we don't move a partition twice within a given number of
62-
# hours (24 is my usual test). Removing a device or setting it's weight
62+
# hours (24 is my usual test). Removing a device or setting its weight
6363
# to 0 overrides this behavior as it's assumed those actions are done
6464
# because of device failure.
6565
# _last_part_moves_epoch indicates the time the offsets in

test/probe/test_object_handoff.py

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -99,7 +99,7 @@ def test_main(self):
9999
exc = True
100100
if not exc:
101101
raise Exception('Previously downed object server had test object')
102-
# Run the extra server last so it'll remove it's extra partition
102+
# Run the extra server last so it'll remove its extra partition
103103
ps = []
104104
for n in onodes:
105105
ps.append(Popen(['swift-object-replicator',
@@ -151,7 +151,7 @@ def test_main(self):
151151
# if oheaders.get('x-object-meta-probe') == 'value':
152152
# raise Exception('Previously downed object server had the new '
153153
# 'metadata when it should not have it')
154-
# # Run the extra server last so it'll remove it's extra partition
154+
# # Run the extra server last so it'll remove its extra partition
155155
# ps = []
156156
# for n in onodes:
157157
# ps.append(Popen(['swift-object-replicator',
@@ -196,7 +196,7 @@ def test_main(self):
196196
sleep(2)
197197
direct_client.direct_get_object(onode, opart, self.account, container,
198198
obj)
199-
# Run the extra server last so it'll remove it's extra partition
199+
# Run the extra server last so it'll remove its extra partition
200200
ps = []
201201
for n in onodes:
202202
ps.append(Popen(['swift-object-replicator',

0 commit comments

Comments
 (0)