openstack/swift - swift - OpenDev: Free Software Needs Free Tools

test_check_delete_headers_removes_delete_after was
failing intermittently due to rounding of float time
values.
Change-Id: Ia126ad6988f387bbd2d1f5ddff0a56d457a1fc9b
Closes-Bug: #1743804 

If we don't drain the body, the proxy logging in the internal client
pipeline will log 499 client disconnect instead of actual error response
code.
For error responses, we try to do the most helpful thing using swob's
closing and caching response body attribute. For non-error responses
which are returned to the client, we endeavour to keep the app_iter
intact and unconsumed, trusting expecting the caller to do the right
thing is the only reasonable interface. We must cleanly close any WSGI
app_iter which we do not return to the client regardless of status code
and allow the logging of the 499 if needed.
Closes-Bug: #1675650
Change-Id: I455b5c38074ad0e72aa5e0b05771e193208905eb

Send just as many requests with X-Delete-At-* as we do X-Container-* to
the object server. Furthermore, stop the object server on making an
update to the expirer queue when it wasn't told to do so and remove the
log warning which would have been produced.
Reason:
It can be the case that the number of object replicas (OR) is larger
than the number of container replicas (CR) for a given storage policy
(most likely in case of EC). Before this commit, only CR object servers
received the x-delete-at-* headers, which means that OR - CR object
servers did not receive the headers. The servers missing the header
would produce a log warning and create the x-delete-at-container header
and async update on their own, which could lead to a bug, if the
expiring_objects_container_divisor option was misconfigured.
Change-Id: I20fc2f42f590fda995814a2fa7ba86019f9fddc1
Closes-Bug: #1733588 

If you want more information, you need to go check out the *other* node.
Maybe this should be further refined to only log at debug for specific
statuses like 404 and 412?
Partial-Bug: 1688558
Related-Bug: 1455221
Change-Id: Ieefd8841154faba40dcf2a03abc5f056bdccd54f

Change-Id: Ia21f8743bfd745f2579db8658624f888461c2cc2

The pointer to using COPY to the same object as a mechanism to set only
a subset of the metadata, it does not mention that doing so results in
a full copy of the object in question on the backend.
Add a note so it's clear that there is a tradeoff involved.
Change-Id: I0c20a4909a6c3ff672f753d26cb9fb2f5f33d1f4

Use https instead of http for some links in readme.rst
Change-Id: Idd382f58108e96129c69c6dc149c694fd7833fb3

...and update the object-expirer man page.
Change-Id: Idca1b8e3b7d5b40481af0d60477510e2557b88c0

... to make testing more targeted and obvious
Related-Change-Id: I89439286b211f2c5ef19deffa77c202f48f07cf8
Change-Id: I93b99128a4fb35395e8e9caf11649e216f824fdf

There are three similar code segments in rebalance process as follows:
 tiers = ['cluster', 'regions', 'zones', 'servers', 'devices']
 for i, tier_name in enumerate(tiers):
 replicas_at_tier = sum(weighted_replicas_by_tier[t] for t in
 weighted_replicas_by_tier if len(t) == i)
 if abs(self.replicas - replicas_at_tier) > 1e-10:
 raise exceptions.RingValidationError(
 '%s != %s at tier %s' % (
 replicas_at_tier, self.replicas, tier_name))
I think we can encapsulate this code segment to a private function and
replace those code segments with a function call
Change-Id: I89439286b211f2c5ef19deffa77c202f48f07cf8

Swift allows autocreate account. It should be treat as server error
instead of 404 when it fails to create account
Change-Id: I726271bc06e3c1b07a4af504c3fd7ddb789bd512
Closes-bug: 1718810

From openstackdocstheme 1.18.0, valid Git URLs can be retrieved by
openstackdocstheme[1], we do not need giturl option anymore.
[1] https://review.openstack.org/532163
Change-Id: I579cebae6486d250915f936f0c1c61008471c089

Added auth_url to the context we pass to castellan
library. In a change [1] intended to deprecate the use
of auth_endpoint passed as the oslo config, it actually
completely removed the use of it[2], so this change became
necessary or the integration is broken.
[1] - https://review.openstack.org/#/c/483457
[2] - https://review.openstack.org/#/c/483457/6/castellan/key_manager/barbican_key_manager.py@143
Change-Id: I933367fa46aa0a3dc9aedf078b1be715bfa8c054

Check that when X-Backend-Clean-Expiring-Object-Queue is true
the object server does indeed call async_update.
Change-Id: I0a87979147591f15349b868a12ac6dd15ac4e37f
Related-Change: I4d64f4d1d107c437fd3c23e19160157fdafbcd42

If you ran this probe test with ssync before the related change it would
demonstrate the related bug. The hack isn't harmful, but it isn't
needed anymore.
Related-Change-Id: I7f90b732c3268cb852b64f17555c631d668044a8
Related-Bug: 1652323
Change-Id: I09e3984a0500a0f4eceec392e7970b84070a5b39

Change-Id: I862b74e0d9b20ba149581c1add6473dc1e5b2859

Currently, on deletion of an expiring object, each object server
writes an async_pending to update the expirer queue and remove the row
for that object. Each async_pending is processed by the object updater
and results in all container replicas being updated. This is also true
for PUT and POST requests for existing expiring objects.
If you have Rc container replicas and Ro object replicas (or EC
pieces), then the number of expirer-queue requests made is Rc * Ro [1].
For a 3-replica cluster, that number is 9, which is not terrible. For
a cluster with 3 container replicas and a 15+4 EC scheme, that number
is 57, which is terrible.
This commit makes it so at most two object servers will write out the
async_pending files needed to update the queue, dropping the request
count to 2 * Rc [2]. The object server now looks for a header
"X-Backend-Clean-Expiring-Object-Queue: <true|false>" and writes or
does not write expirer-queue async_pendings as appropriate. The proxy
sends that header to 2 object servers.
The queue update is not necessary for the proper functioning of the
object expirer; if the queue update fails, then the object expirer
will try to delete the object, receive 404s or 412s, and remove the
queue entry. Removal on object PUT/POST/DELETE is helpful but not
required.
[1] assuming no retries needed by the object updater
[2] or Rc, if a cluster has only one object replica
Change-Id: I4d64f4d1d107c437fd3c23e19160157fdafbcd42

Displaying an empty ring should not be an error, thus
changing the exit code back to the former value of 0.
Closes-Bug: 1742417
Change-Id: I779c30cff1b4d24483f993221a8c6d944b7ae98d

When the proxy is putting X-Container headers into object PUT
requests, it should put out just enough to make the container update
durable in the worst case. It shouldn't do more, since that results in
extra work for the container servers; and it shouldn't do less, since
that results in objects not showing up in listings.
The current code gets the number right as long as you have 3 container
replicas and an odd number of object replicas, but it comes up with
some bogus numbers in other cases. The number it computes is
(object-quorum + 1).
This patch changes the number to (container-quorum +
max_put_failures).
Example: given an EC 12+5 policy and 3 container replicas, you can
lose up to 4 connections and still succeed. Since you need to have 2
container updates happen for durability, you need 6 connections to
have X-Container headers. That way, you can lose 4 and still have 2
left. The current code would put X-Container headers on 14 of the
connections, resulting in more than double the workload on the
container servers; this patch changes the number to 6.
Example 2: given a (crazy) EC 3+6 policy and 3 container replicas, you
can lose up to 5 connections, so you need X-Container headers on
7. The current code only sends 5, giving a worst-case result of a PUT
succeeds but never reaches the containers. This patch changes the
number to 7.
Other examples:
 | current | this change |
 --+-----------+---------------+
EC 10+4, 3x container | 12 | 5 |
EC 10+4, 5x container | 12 | 6 |
EC 15+4, 3x container | 17 | 5 |
EC 15+4, 5x container | 17 | 6 |
EC 4+8, 3x container | 6 | 9 |
7x object, 3x container | 5 | 5 |
6x object, 3x container | 4 | 5 |
Change-Id: I34efd48655b890340912810ab111bb63445e5c8b

This includes every pipeline from etc/proxy-server.conf-sample since we
switched from swauth to tempauth in 1.4.1. As much as anything, I view
this as a canary for auto-insertion changes, so we can (somewhat easily)
see where new middlewares will be placed when upgrading from old swifts.
Change-Id: I117937ab6ce28f3bc219e809f07b563c45fc486f
Related-Change: I88678fddc7a25b0f065b33eb26047321d0db4d38

The DELETE method repeats inline the same behaviour as provided by
_update_x_timestamp, so just call the method.
Also add unit tests for the behaviour of _update_x_timestamp.
Change-Id: I8b6cfdbfb54b6d43ac507f23d84309ab543374aa

This is a follow up patch to 530258 which will show
extra infromation on empty rings.
This patch goes one step further. On a completely empty ring:
 $ swift-ring-builder my.builder create 8 3 1
 $ swift-ring-builder my.builder
 my.builder, build version 0, id 33b4e117056340feae7d40430180c6bb
 256 partitions, 3.000000 replicas, 0 regions, 0 zones, 0 devices, 0.00 balance, 0.00 dispersion
 The minimum number of hours before a partition can be reassigned is 1 (0:00:00 remaining)
 The overload factor is 0.00% (0.000000)
 Ring file my.ring.gz not found, probably it hasn't been written yet
 Devices: id region zone ip address:port replication ip:port name weight partitions balance flags meta
 There are no devices in this ring, or all devices have been deleted
It will still start the device list and then say no devices.. Why. let's
see what happens now on an empty ring with devices still marked as
deleted:
 $ swift-ring-builder my.builder add r1z1-127.0.0.1:6010/sdb1 1
 Device d0r1z1-127.0.0.1:6010R127.0.0.1:6010/sdb1_"" with 1.0 weight got id 0
 $ swift-ring-builder my.builder add r1z1-127.0.0.1:6010/sdb2 1
 Device d1r1z1-127.0.0.1:6010R127.0.0.1:6010/sdb2_"" with 1.0 weight got id 1
 $ swift-ring-builder my.builder remove r1z1-127.0.0.1
 Matched more than one device:
 d0r1z1-127.0.0.1:6010R127.0.0.1:6010/sdb1_""
 d1r1z1-127.0.0.1:6010R127.0.0.1:6010/sdb2_""
 Are you sure you want to remove these 2 devices? (y/N) y
 d0r1z1-127.0.0.1:6010R127.0.0.1:6010/sdb1_"" marked for removal and will be removed next rebalance.
 d1r1z1-127.0.0.1:6010R127.0.0.1:6010/sdb2_"" marked for removal and will be removed next rebalance.
 $ swift-ring-builder my.builder
 my.builder, build version 4, id 33b4e117056340feae7d40430180c6bb
 256 partitions, 3.000000 replicas, 1 regions, 1 zones, 2 devices, 0.00 balance, 0.00 dispersion
 The minimum number of hours before a partition can be reassigned is 1 (0:00:00 remaining)
 The overload factor is 0.00% (0.000000)
 Ring file my.ring.gz not found, probably it hasn't been written yet
 Devices: id region zone ip address:port replication ip:port name weight partitions balance flags meta
 0 1 1 127.0.0.1:6010 127.0.0.1:6010 sdb1 0.00 0 0.00 DEL
 1 1 1 127.0.0.1:6010 127.0.0.1:6010 sdb2 0.00 0 0.00 DEL
 There are no devices in this ring, or all devices have been deleted
Now even when all devices are removed we can still see them as they are still there, only marked as deleted.
Change-Id: Ib39f734deb67ad50bcdad5333cba716161a47e95

These were likely written before the first related change, or created
from an existing ring file.
Also, tolerate missing dispersion when rebalancing -- that may not exist
in the builder file.
Change-Id: I26e3b4429c747c23206e4671f7c86543bb182a15
Related-Change: Ib165cf974c865d47c2d9e8f7b3641971d2e9f404
Related-Change: Ie239b958fc7e0547ffda2bebf61546bd4ef3d829
Related-Change: I551fcaf274876861feb12848749590f220842d68

Previously an x-delete-at value equal to the x-timestamp value was
allowed. This could only occur when x-timestamp happened to take an
integer value and would result in an object that was immediately
unreadable.
Similarly an x-delete-after value of zero may previously have been
accepted if x-timestamp happened to be an integer value.
With this change an x-delete-at value equal to x-timestamp or an
x-delete-after value of zero always results in a 400 BadRequest.
Also cleans up check_delete_headers docstring.
Related-Change: Ia8d00fcef8893e3b3dd5720da2c8a5ae1e6e4cb8
Related-Change: Ib2483444d3999e13ba83ca2edd3a8ef8e5c48548
Change-Id: I27fdd800d8e149302ff4d6531101e9726a14d471

Use a utils.Timestamp object to set a more realistic x-timestamp
header to avoid intermittent failure when str(time.time()) results
in a rounded up value.
Closes-Bug: 1741912
Change-Id: I0c54d07e30ecb391f9429e7bcfb782f965ece1ea

Before an x-delete-after header with value '0' would almost
certainly result in a 400 response, but the response body would
report a problem with x-delete-at. Now the response correctly
blames the x-delete-after header.
Related-Change: I9a1b6826c4c553f0442cfe2bb78cdf49508fa4a5
Change-Id: Ia8d00fcef8893e3b3dd5720da2c8a5ae1e6e4cb8

There was incorrect path starting /home/swift, but /home/<your-user-name> is correct for common users.
Change-Id: Ia81b2119c87dd88417428e55c82dac1ab7c028b3
Closes-Bug: 1741378