Swift servers can now be seamlessly reloaded by sending them a SIGUSR1
(instead of a SIGHUP). The server forks off a synchronized child to
wait to close the old listen socket(s) until the new server has started
up and bound its listen socket(s). The new server is exec'ed from the
old one so its PID doesn't change. This makes Systemd happier, so a
ReloadExec= stanza can now be used.
The seamless part means that incoming connections will alwyas get
accepted either by the old server or the new one. This eliminates
client-perceived "downtime" during server reloads, while allowing the
server to fully reload, re-reading configuration, becoming a fresh
Python interpreter instance, etc. The SO_REUSEPORT socket option has
already been getting used, so nothing had to change there.
This patch also includes a non-invasive fix for a current eventlet bug;
see https://github.com/eventlet/eventlet/pull/590
That bug prevents a SIGHUP "reload" from properly servicing existing
requests before old worker processes close sockets and exit. The
existing probtests missed this, but the new ones, in this patch, caught
it.
New probe tests cover both old SIGHUP "reload" behavior as well as the
new SIGUSR1 seamless reload behavior.
Change-Id: I3e5229d2fb04be67e53533ff65b0870038accbb7
During a PUT of an object, the proxy instanciates one Putter per
object-server that will store data (either the full object or a
fragment, depending on the storage policy). Each Putter is owning a
Queue that will be used to bufferize data chunks before they are
written to the socket connected to the object-server. The chunks are
moved from the queue to the socket by a greenthread. There is one
greenthread per Putter. If the client is uploading faster than the
object-servers can manage, the Queue could grow and consume a lot of
memory. To avoid that, the queue is bounded (default: 10). Having a
bounded queue also allows to ensure that all object-servers will get
the data at the same rate because if one queue is full, the
greenthread reading from the client socket will block when trying to
write to the queue. So the global rate is the one of the slowest
object-server.
The thing is, every operating system manages socket buffers for incoming
and outgoing data. Concerning the send buffer, the behavior is such that
if the buffer is full, a call to write() will block, otherwise the call
will return immediately. It behaves a lot like the Putter's Queue,
except that the size of the buffer is dynamic so it adapts itself to the
speed of the receiver.
Thus, managing a queue in addition to the socket send buffer is a
duplicate queueing/buffering that provides no interest but is, as shown
by profiling and benchmarks, very CPU costly.
This patch removes the queuing mecanism. Instead, the greenthread
reading data from the client will directly write to the socket. If an
object-server is getting slow, the buffer will fulfill, blocking the
reader greenthread. Benchmark shows a CPU consumption reduction of more
than 30% will the observed rate for an upload is increasing by about
45%.
Change-Id: Icf8f800cb25096f93d3faa1e6ec091eb29500758
The Swift AIO documentation is out of date for CentOS and Fedora.
This patch updates the documentation to ensure that the instructions are
clear and accurate.
It also cleans up a few other sections along the way and adds some new
headings to make it easier to read. Some explanatory notes are added,
such as the need for XFS storage and test directories. XFS tmp loopback
device is moved out of the user's home directory to /srv to match
storage.
Change-Id: Ieb0341536b7149c99139a1cf620828eba25f4bc6
Signed-off-by: Chris Smart <chris.smart@humanservices.gov.au>
This patch adds a `pdf-docs` tox target that will build
PDF versions of our docs. As per the Train community goal:
https://governance.openstack.org/tc/goals/selected/train/pdf-doc-generation.html
Add sphinxcontrib-svg2pdfconverter to doc/requirements.txt
to convert our SVGs.
Story: 2006122
Task: 35515
Change-Id: I26cefda80d3234df68d7152b404e0a71da74ab90
The api documentation is now published on docs.openstack.org instead
of developer.openstack.org. Update all links that are changed to the
new location.
Note that the Swift API lives at /object-store and not /object-storage.
Note that redirects will be set up as well but let's point now to the
new location.
For details, see:
http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007828.html
Change-Id: Ie38357e4c278335c35d186708573bb6bdabaa012
Beginning with the Queens release, the keystone install guide
recommends running all interfaces on the same port.This patch
updates the swift install guide to reflect that change
Change-Id: Id00cfd2c921da352abdbbbb6668b921f3cb31a1a
Closes-bug: #1754104
XFS no longer supports nobarrier mount option.
It has been deprecated for a long time[1] and removed in
recent kernel versions resulting in an error when trying to
mount: "kernel: XFS (loop0): unknown mount option [nobarrier]."
[1] - https://patchwork.kernel.org/patch/9486549/
Change-Id: Iaa9208fb20545ae9ac990f0e180899108d983123
This precludes us from landing anything in the gate, because we
treat Sphinx warnings as errors in OpenStack.
Specifically, 3 warnings are fixed:
/home/zuul/src/opendev.org/openstack/swift/swift/common/middleware\
/s3api/etree.py:docstring of\
swift.common.middleware.s3api.etree.Element:1:\
Inline strong start-string without end-string.
duplicate object description of\
swift.common.middleware.versioned_writes, other instance in\
middleware, use :noindex: for one of them
duplicate object description of\
swift.common.ring.composite_builder, other instance in\
overview_ring, use :noindex: for one of them
Change-Id: I5e0bd61a301d46b2674b4605882462575b635220
In the main branch, I think it is necessary to modify
the configuration file path in the document as the
main branch path, and to change the path to a stable
version when the version is released.
Change-Id: Ib1bc4c59ed4c7624782b8b1cdea20847c14c90bf
Adds the scaffolding required for tests to use boto3 and converts the
test_bucket.py tests to the new interface. Follow on patches will
convert the other tests to use the boto3 library.
Notable changes: we no longer try to reach for the equivalent of
`boto.make_request()` and instead rely on the boto3/botocore event
system to mutate requests as necessary (or to disable pre-flight
validators).
Partial-Bug: 1557260
Change-Id: I3d77ef4a6b878c49ebfa0c8b8647d7199d87601e
S3 supports two metadata operations on object copy: COPY and REPLACE.
When using REPLACE, the Content-Type should be set to the one supplied
by the caller. When using COPY, the existing object's Content-Type value
is used.
Change-Id: Ic7c6278dedef308c9219eb45751abfa5655f144f
Closes-Bug: #1828907
Added a test for S3 v1 listings that use URL encoding and have non-ASCII
characters. In the process discovered that the XML schema for
ListBucketResult had a small problem: Delimiter and EncodingType needed
to be reordered.
Change-Id: Ib3124ea079a73a577b86de97657603a64b16f965
To prepare for object-expirer's general task queue feature [1],
this patch enables to configure object-expirer in object-server.conf.
Object-expirer.conf can be used in the same manner as before, but deprecated.
If both of object-server.conf with "object-expirer" section and
object-expirer.conf are in a node, only object-server.conf is used.
Object-expirer.conf is used only if all object-server.conf doesn't have
"object-expirer" section.
There are two differences between "object-expirer.conf" style and
"object-server.conf" style.
The first difference is `dequeue_from_legacy` default value.
`dequeue_from_legacy` defines task queue mode. In "object-expirer.conf"
style, the default mode is legacy queue. In "object-server.conf" style,
the default mode is general queue. But general mode means no-op mode
for now, because general task queue is not implemented yet.
The second difference is internal client config. In "object-expirer.conf"
style, config file of internal client is the object-expirer.conf itself.
In "object-server.conf" style, config file of internal client is
another file.
[1]: https://review.openstack.org/#/c/517389/
Co-Authored-By: Matthew Oliver <matt@oliver.net.au>
Change-Id: Ib21568f9b9d8547da87a99d65ae73a550e9c3230
Add the log_msg_template option in proxy-server.conf and log_format in
a/c/o-server.conf. It is a string parsable by Python's format()
function. Some fields containing user data might be anonymized by using
log_anonymization_method and log_anonymization_salt.
Change-Id: I29e30ef45fe3f8a026e7897127ffae08a6a80cd9
It was a recommended practice for years to get away from straight
names in /dev, like /dev/sda1, when mounting filesystems. The
man page for mount(8) says:
The device name of disk partitions are unstable; hardware
reconfiguration, adding or removing a device can cause change
in names. This is reason why it's strongly recommended to use
filesystem or partition identificators like UUID or LABEL.
Nonetheless, novice operators sometimes follow our deployment
guide to the letter and then get into trouble when device names
shift from under their deployments. This patch fixes the problem
without bloating up the guide with general explanations.
Change-Id: I5faae158b62e0395d6e774cd67bd868c785c2186
At the moment, the `get_data_dir` ref in [0] is not
pointing to anything. This patch amends that and
links it to the correct policy string.
Without updating this change, local tox builds
for swift documentation fail with the following
error: Warning, treated as error: /home/asettle/openstack/swift/doc
/source/overview_policies.rst:555:more than one target found for
cross-reference u'get_data_dir': swift.obj.reconstructor.get_data_dir,
swift.obj.diskfile.get_data_dir, swift.obj.replicator.get_data_dir
[0] https://docs.openstack.org/swift/rocky/overview_policies.html#object-server
Change-Id: I7c699e4fc46706a4971fce5a85ed335f471d3a2b
To increase performance of the s3 API retrieve and cache s3 secret
from keystone to allow for local validation.
Disabled by default, to use set 'secret_cache_duration' to a
number greater than 0.
You will also need to configure keystone auth credentials in
the s3token configuration group too. These credentials will
need to be able to view all projects credentials in keystone.
Change-Id: Id0c01da6aa6ca804c8f49a307b5171b87ec92228
This patch updates the overview_encryption page to add a
`Changing the encryption root secret of external KMS's` section
to point out the slight difference in naming. I.E:
key_id_<secret_id> vs. encryption_root_secret_<secret_id>
This patch refers to both multikey support in the KMIP and KMS
key masters, so really should land after both of them.
Related-Change-Id: Ie52508e47d15ec5c4e96902d3c9f5f282d275683
Related-Change-Id: I4f485dcb31e5bea511c4e539c54681091fc5bb1c
Change-Id: Ie4cd8ae038501c8abc43d09cf0b207ca375a4366
Most daemons have a "go as fast as you can then sleep for 30 seconds"
strategy towards resource utilization; the object-updater and
object-auditor however have some "X_per_second" options that allow
operators much better control over how they spend their I/O budget.
This change extends that pattern into the account-replicator,
container-replicator, and container-sharder which have been known to peg
CPUs when they're not IO limited.
Partial-Bug: #1784753
Change-Id: Ib7f2497794fa2f384a1a6ab500b657c624426384
