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
The requirements repo is support python 3.5 as oldest python version
while swift still supports py27.
thus, requirements-check will fail on a couple of lines in swift. The
check is only run when these files are touched.
The py2.7 packagers we know about aren't depending on upstream
requirements.txt for correctness and aside from all the production
deployments running on py2.7 we only realistically support >=py3.7
There's no good reason for our requirements.txt to be "unspported" by
the openstack requirements check job. Since they only support >=py3.5
we can change our requirements.txt inline with that. This should be
fine for everything we could hope to get out of both our
requirements.txt and the check!
Co-Authored-By: Clay Gerrard <clay.gerrard@gmail.com>
Change-Id: Ibf8000498528c401707be8b0b91b8355cd993786
This patch removed the separate s3api, staticweb functional tests
gate jobs and added them across all other functional test jobs.
Change-Id: Ie1c606132a054defc2b3cc14a66031090e7b8449
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
Previously, the lack of container ACLs on the reserved container would
mean that attempting to grant access to the user-visible container would
not work; the user could not access the backing object.
Now, have symlinks with the allow-reserved-names sysmeta set be
pre-authed. Note that the user still has to be authorized to read the
symlink, and if the backing object was *itself* a symlink, that will be
authed separately.
Change-Id: Ifd744044421ef2ca917ce9502b155a6514ce8ecf
Closes-Bug: #1880013
We want to do the table scan without locking and group the locking
deletes into small indexed operations to minimize the impact of
background processes calling reclaim each cycle.
Change-Id: I3ccd145c14a9b68ff8a9da61f79034549c9bc127
Co-Authored-By: Tim Burke <tim.burke@gmail.com>
Closes-Bug: #1877651
DSVM recently got a bunch more middlewares enabled, so it's running more
tests than it used to.
I can't think of much that's changed for probe tests, but I feel like
I've seen it popping timeouts more often lately.
Note that the new timeouts are still lower than the typical run-time of
our longest-running jobs (currently grenade / tempest-ipv6-only).
Change-Id: Iffbb567124096df02b04981550faec8204d5d1ec
Related-Change: I3cbbcd2ea9ced0923bee4a6b0783e4cf5e82e95b
We usually want to have ratelimit fairly far left in the pipeline -- the
assumption is that something like an auth check will be fairly expensive
and we should try to shield the auth system so it doesn't melt under the
load of a misbehaved swift client.
But with S3 requests, we can't know the account/container that a request
is destined for until *after* auth. Fortunately, we've already got some
code to make s3api play well with ratelimit.
So, let's have our cake and eat it, too: allow operators to place
ratelimit once, before auth, for swift requests and again, after auth,
for s3api. They'll both use the same memcached keys (so users can't
switch APIs to effectively double their limit), but still only have each
S3 request counted against the limit once.
Change-Id: If003bb43f39427fe47a0f5a01dbcc19e1b3b67ef
New flake8 came out with new & improved rules. Ignore E741; it would be
too much churn. Fix the rest.
Change-Id: I9125c8c53423232309a75cbcc5b695b378864c1b
When tuning your updater, you often want to try a new config, see how it
changes your metrics, then adjust concurrency up or down depending on
how your container layer is responding.
If your containers haven't been doing well, though, and you've got a
giant backlog of async pendings to work through, updater restarts to
change concurrency previously posed a problem: the updater would walk
the suffix directories in the same order every start-up. So, if you
found a config that was making decent progress for a while but still had
*some* failures, and you wanted to try tweaking settings to see if you
could *reduce* those failures -- you'd likely start getting *all*
failures as it went to retry the failed ones first and all at once. If
you continued trying to tweak configs to get your failures to a
reasonable rate, you'd almost certainly over-correct for these handful
of overwhelmed DBs and not the overall cluster.
Now, shuffle the suffixes before we walk them.
Change-Id: I3ef34119f0cb563ab405a6517335a24dbaf2b4c3
Closes-Bug: #1878056
