Switch to openstackdocstheme 2.2.1 and reno 3.1.0 versions. Using
these versions will allow especially:
* Linking from HTML to PDF document
* Allow parallel building of documents
* Fix some rendering problems
Update Sphinx version as well.
Disable openstackdocs_auto_name to use 'project' variable as name.
Set openstackdocs_pdf_link to link to PDF file. Note that
the link to the published document only works on docs.openstack.org
where the PDF file is placed in the top-level html directory. The
site-preview places the PDF in a pdf directory.
Change pygments_style to 'native' since old theme version always used
'native' and the theme now respects the setting and using 'sphinx' can
lead to some strange rendering.
Remove docs requirements from lower-constraints, they are not needed
during install or test but only for docs building.
openstackdocstheme renames some variables, so follow the renames
before the next release removes them. A couple of variables are also
not needed anymore, remove them.
See also
http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014971.html
Change-Id: I131850d2a5c6164dfd48c9c95885d4754b5236c6
This patch standardizes the CONTRIBUTING.rst file and adds the
required doc/source/contributor/contributing.rst
Swift already had a detailed CONTIRBUTING.rst and an informative
REVIEW_GUIDELINES.rst in the root of the repo. So we are also pulling
them into the contributor documentation so they can not only be easily
found in the checked repo but in the online documentation.
Change-Id: I4c84efbe50eb25ab922c9d6b69198dae341af48b
* Stop specifying logbufs=8; that's the default
* Stop including nodiratime with noatime; the latter implies the former
Nothing wrong with being explicit, I suppose, but may as well keep the
mount options to what we can easily explain: we want noatime because
Swift does not use atime, so we don't want to lose any performance to
tracking atime.
Change-Id: I1e52b4368ad7eb375964eee5132bc50297536355
Update doc examples to use explicit UUID of devices, instead of using
unstable device names.
Change-Id: I3a2eb7bbe4b4091d2567897904d939df1df6b251
Closes-Bug: #1817966
Specify that the relink command must be run as the same user than the
daemon processes to avoid creating files that are not manipulable by the
server/replicator/...
Change-Id: If23592855db5f5bb0ec1e7c679de15769fd86871
Users have complained for a while that Swift's ETags don't match the
expected RFC formats. We've resisted fixing this for just as long,
worrying that the fix would break innumerable clients that expect the
value to be a hex-encoded MD5 digest and *nothing else*.
But, users keep asking for it, and some consumers (including some CDNs)
break if we *don't* have quoted etags -- so, let's make it an option.
With this middleware, Swift users can set metadata per-account or even
per-container to explicitly request RFC compliant etags or not. Swift
operators also get an option to change the default behavior
cluster-wide; it defaults to the old, non-compliant format.
See also:
- https://tools.ietf.org/html/rfc2616#section-3.11
- https://tools.ietf.org/html/rfc7232#section-2.3
Closes-Bug: 1099087
Closes-Bug: 1424614
Co-Authored-By: Tim Burke <tim.burke@gmail.com>
Change-Id: I380c6e34949d857158e11eb428b3eda9975d855d
This patch adds a new object versioning mode. This new mode provides
a new set of APIs for users to interact with older versions of an
object. It also changes the naming scheme of older versions and adds
a version-id to each object.
This new mode is not backwards compatible or interchangeable with the
other two modes (i.e., stack and history), especially due to the changes
in the namimg scheme of older versions. This new mode will also serve
as a foundation for adding S3 versioning compatibility in the s3api
middleware.
Note that this does not (yet) support using a versioned container as
a source in container-sync. Container sync should be enhanced to sync
previous versions of objects.
Change-Id: Ic7d39ba425ca324eeb4543a2ce8d03428e2225a1
Co-Authored-By: Clay Gerrard <clay.gerrard@gmail.com>
Co-Authored-By: Tim Burke <tim.burke@gmail.com>
Co-Authored-By: Thiago da Silva <thiagodasilva@gmail.com>
This allows static symlinks to be synced before their target. Dynamic
symlinks could already be synced even if target object has not been
synced, but static links previously required that target object existed
before it can be PUT. Now, have container_sync middleware plumb in an
override like it does for SLO.
Change-Id: I3bfc62b77b247003adcee6bd4d374168bfd6707d
This is to fix the duplicated words issue, like:
* "both of which which must be stripped off"
* "In addition the the values set"
and so on
Change-Id: Id3d84281f15815b4185c76874575e91a3589981b
If we move it to constraints it's more globally accessible in our code,
but more importantly it's more obvious to ops that everything breaks if
you try to mis-configure different values per-service.
Change-Id: Ib8f7d08bc48da12be5671abe91a17ae2b49ecfee
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
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
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
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
