2013-09-20 01:00:54 +08:00
|
|
|
# Copyright (c) 2010-2012 OpenStack Foundation
|
2010-07-12 17:03:45 -05:00
|
|
|
#
|
|
|
|
# Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
# you may not use this file except in compliance with the License.
|
|
|
|
# You may obtain a copy of the License at
|
|
|
|
#
|
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
#
|
|
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
|
|
# distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
|
|
# implied.
|
|
|
|
# See the License for the specific language governing permissions and
|
|
|
|
# limitations under the License.
|
|
|
|
|
2015-07-07 22:46:37 +05:30
|
|
|
import six.moves.cPickle as pickle
|
2013-11-26 15:08:13 -05:00
|
|
|
import mock
|
2010-07-12 17:03:45 -05:00
|
|
|
import os
|
|
|
|
import unittest
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
import random
|
|
|
|
import itertools
|
2013-07-20 13:44:11 -07:00
|
|
|
from contextlib import closing
|
2010-07-12 17:03:45 -05:00
|
|
|
from gzip import GzipFile
|
2014-01-16 00:49:28 -05:00
|
|
|
from tempfile import mkdtemp
|
2010-07-12 17:03:45 -05:00
|
|
|
from shutil import rmtree
|
2017-05-11 01:39:14 -06:00
|
|
|
from test import listen_zero
|
2017-09-01 14:15:45 -07:00
|
|
|
from test.unit import (
|
Improve object-updater's stats logging
The object updater has five different stats, but its logging only told
you two of them (successes and failures), and it only told you after
finishing all the async_pendings for a device. If you have a cluster
that's been sick and has millions upon millions of async_pendings
laying around, then your object-updaters are frustratingly
silent. I've seen one cluster with around 8 million async_pendings per
disk where the object-updaters only emitted stats every 12 hours.
Yes, if you have StatsD logging set up properly, you can go look at
your graphs and get real-time feedback on what it's doing. If you
don't have that, all you get is a frustrating silence.
Now, the object updater tells you all of its stats (successes,
failures, quarantines due to bad pickles, unlinks, and errors), and it
tells you incremental progress every five minutes. The logging at the
end of a pass remains and has been expanded to also include all stats.
Also included is a small change to what counts as an error: unmounted
drives no longer do. The goal is that only abnormal things count as
errors, like permission problems, malformed filenames, and so
on. These are things that should never happen, but if they do, may
require operator intervention. Drives fail, so logging an error upon
encountering an unmounted drive is not useful.
Change-Id: Idbddd507f0b633d14dffb7a9834fce93a10359ab
2018-01-12 07:17:18 -08:00
|
|
|
make_timestamp_iter, debug_logger, patch_policies, mocked_http_conn,
|
|
|
|
FakeLogger)
|
2010-07-12 17:03:45 -05:00
|
|
|
from time import time
|
2011-04-20 19:54:28 +00:00
|
|
|
from distutils.dir_util import mkpath
|
2010-07-12 17:03:45 -05:00
|
|
|
|
2017-05-11 01:39:14 -06:00
|
|
|
from eventlet import spawn, Timeout
|
2010-07-12 17:03:45 -05:00
|
|
|
|
DiskFile API, with reference implementation
Refactor on-disk knowledge out of the object server by pushing the
async update pickle creation to the new DiskFileManager class (name is
not the best, so suggestions welcome), along with the REPLICATOR
method logic. We also move the mount checking and thread pool storage
to the new ondisk.Devices object, which then also becomes the new home
of the audit_location_generator method.
For the object server, a new setup() method is now called at the end
of the controller's construction, and the _diskfile() method has been
renamed to get_diskfile(), to allow implementation specific behavior.
We then hide the need for the REST API layer to know how and where
quarantining needs to be performed. There are now two places it is
checked internally, on open() where we verify the content-length,
name, and x-timestamp metadata, and in the reader on close where the
etag metadata is checked if the entire file was read.
We add a reader class to allow implementations to isolate the WSGI
handling code for that specific environment (it is used no-where else
in the REST APIs). This simplifies the caller's code to just use a
"with" statement once open to avoid multiple points where close needs
to be called.
For a full historical comparison, including the usage patterns see:
https://gist.github.com/portante/5488238
(as of master, 2b639f5, Merge
"Fix 500 from account-quota This Commit
middleware")
--------------------------------+------------------------------------
DiskFileManager(conf)
Methods:
.pickle_async_update()
.get_diskfile()
.get_hashes()
Attributes:
.devices
.logger
.disk_chunk_size
.keep_cache_size
.bytes_per_sync
DiskFile(a,c,o,keep_data_fp=) DiskFile(a,c,o)
Methods: Methods:
*.__iter__()
.close(verify_file=)
.is_deleted()
.is_expired()
.quarantine()
.get_data_file_size()
.open()
.read_metadata()
.create() .create()
.write_metadata()
.delete() .delete()
Attributes: Attributes:
.quarantined_dir
.keep_cache
.metadata
*DiskFileReader()
Methods:
.__iter__()
.close()
Attributes:
+.was_quarantined
DiskWriter() DiskFileWriter()
Methods: Methods:
.write() .write()
.put() .put()
* Note that the DiskFile class * Note that the DiskReader() object
implements all the methods returned by the
necessary for a WSGI app DiskFileOpened.reader() method
iterator implements all the methods
necessary for a WSGI app iterator
+ Note that if the auditor is
refactored to not use the DiskFile
class, see
https://review.openstack.org/44787
then we don't need the
was_quarantined attribute
A reference "in-memory" object server implementation of a backend
DiskFile class in swift/obj/mem_server.py and
swift/obj/mem_diskfile.py.
One can also reference
https://github.com/portante/gluster-swift/commits/diskfile for the
proposed integration with the gluster-swift code based on these
changes.
Change-Id: I44e153fdb405a5743e9c05349008f94136764916
Signed-off-by: Peter Portante <peter.portante@redhat.com>
2013-09-12 19:51:18 -04:00
|
|
|
from swift.obj import updater as object_updater
|
2017-09-01 14:15:45 -07:00
|
|
|
from swift.obj.diskfile import (
|
|
|
|
ASYNCDIR_BASE, get_async_dir, DiskFileManager, get_tmp_dir)
|
2010-07-12 17:03:45 -05:00
|
|
|
from swift.common.ring import RingData
|
2013-10-07 12:10:31 +00:00
|
|
|
from swift.common import utils
|
2016-03-02 10:28:51 +00:00
|
|
|
from swift.common.header_key_dict import HeaderKeyDict
|
2019-07-25 10:56:53 -07:00
|
|
|
from swift.common.swob import bytes_to_wsgi
|
2017-09-01 14:15:45 -07:00
|
|
|
from swift.common.utils import (
|
|
|
|
hash_path, normalize_timestamp, mkdirs, write_pickle)
|
2014-06-23 12:52:50 -07:00
|
|
|
from swift.common.storage_policy import StoragePolicy, POLICIES
|
2010-07-12 17:03:45 -05:00
|
|
|
|
|
|
|
|
object-updater: add concurrent updates
The object updater now supports two configuration settings:
"concurrency" and "updater_workers". The latter controls how many
worker processes are spawned, while the former controls how many
concurrent container updates are performed by each worker
process. This should speed the processing of async_pendings.
There is a change to the semantics of the configuration
options. Previously, "concurrency" controlled the number of worker
processes spawned, and "updater_workers" did not exist. I switched the
meanings for consistency with other configuration options. In the
object reconstructor, object replicator, object server, object
expirer, container replicator, container server, account replicator,
account server, and account reaper, "concurrency" refers to the number
of concurrent tasks performed within one process (for reference, the
container updater and object auditor use "concurrency" to mean number
of processes).
On upgrade, a node configured with concurrency=N will still handle
async updates N-at-a-time, but will do so using only one process
instead of N.
UpgradeImpact:
If you have a config file like this:
[object-updater]
concurrency = <N>
and you want to take advantage of faster updates, then do this:
[object-updater]
concurrency = 8 # the default; you can omit this line
updater_workers = <N>
If you want updates to be processed exactly as before, do this:
[object-updater]
concurrency = 1
updater_workers = <N>
Change-Id: I17e18088e61f664e1b9942d66423666d0cae1689
2018-06-04 16:26:50 -07:00
|
|
|
class MockPool(object):
|
|
|
|
def __init__(self, *a, **kw):
|
|
|
|
pass
|
|
|
|
|
|
|
|
def spawn(self, func, *args, **kwargs):
|
|
|
|
func(*args, **kwargs)
|
|
|
|
|
|
|
|
def waitall(self):
|
|
|
|
pass
|
|
|
|
|
|
|
|
def __enter__(self):
|
|
|
|
return self
|
|
|
|
|
|
|
|
def __exit__(self, *a, **kw):
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
_mocked_policies = [StoragePolicy(0, 'zero', False),
|
|
|
|
StoragePolicy(1, 'one', True)]
|
|
|
|
|
|
|
|
|
|
|
|
@patch_policies(_mocked_policies)
|
2010-07-12 17:03:45 -05:00
|
|
|
class TestObjectUpdater(unittest.TestCase):
|
|
|
|
|
|
|
|
def setUp(self):
|
2018-11-01 17:49:35 +00:00
|
|
|
utils.HASH_PATH_SUFFIX = b'endcap'
|
|
|
|
utils.HASH_PATH_PREFIX = b''
|
2014-01-16 00:49:28 -05:00
|
|
|
self.testdir = mkdtemp()
|
2013-07-20 13:44:11 -07:00
|
|
|
ring_file = os.path.join(self.testdir, 'container.ring.gz')
|
|
|
|
with closing(GzipFile(ring_file, 'wb')) as f:
|
|
|
|
pickle.dump(
|
2013-11-26 15:08:13 -05:00
|
|
|
RingData([[0, 1, 2, 0, 1, 2],
|
|
|
|
[1, 2, 0, 1, 2, 0],
|
|
|
|
[2, 3, 1, 2, 3, 1]],
|
2013-08-31 23:13:15 -04:00
|
|
|
[{'id': 0, 'ip': '127.0.0.1', 'port': 1,
|
|
|
|
'device': 'sda1', 'zone': 0},
|
|
|
|
{'id': 1, 'ip': '127.0.0.1', 'port': 1,
|
2013-11-26 15:08:13 -05:00
|
|
|
'device': 'sda1', 'zone': 2},
|
|
|
|
{'id': 2, 'ip': '127.0.0.1', 'port': 1,
|
2018-05-02 10:21:11 +01:00
|
|
|
'device': 'sda1', 'zone': 4},
|
|
|
|
{'id': 3, 'ip': '127.0.0.1', 'port': 1,
|
|
|
|
'device': 'sda1', 'zone': 6}], 30),
|
2013-07-20 13:44:11 -07:00
|
|
|
f)
|
2010-07-12 17:03:45 -05:00
|
|
|
self.devices_dir = os.path.join(self.testdir, 'devices')
|
|
|
|
os.mkdir(self.devices_dir)
|
|
|
|
self.sda1 = os.path.join(self.devices_dir, 'sda1')
|
|
|
|
os.mkdir(self.sda1)
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
for policy in POLICIES:
|
2015-03-17 08:32:57 +00:00
|
|
|
os.mkdir(os.path.join(self.sda1, get_tmp_dir(policy)))
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
self.logger = debug_logger()
|
2018-05-02 10:21:11 +01:00
|
|
|
self.ts_iter = make_timestamp_iter()
|
2010-07-12 17:03:45 -05:00
|
|
|
|
|
|
|
def tearDown(self):
|
|
|
|
rmtree(self.testdir, ignore_errors=1)
|
|
|
|
|
|
|
|
def test_creation(self):
|
2016-12-01 19:58:08 +09:00
|
|
|
ou = object_updater.ObjectUpdater({
|
2010-08-20 00:42:38 +00:00
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'false',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
'interval': '1',
|
|
|
|
'concurrency': '2',
|
2015-10-23 16:38:24 +01:00
|
|
|
'node_timeout': '5.5'})
|
2016-12-01 19:58:08 +09:00
|
|
|
self.assertTrue(hasattr(ou, 'logger'))
|
|
|
|
self.assertTrue(ou.logger is not None)
|
|
|
|
self.assertEqual(ou.devices, self.devices_dir)
|
|
|
|
self.assertEqual(ou.interval, 1)
|
|
|
|
self.assertEqual(ou.concurrency, 2)
|
|
|
|
self.assertEqual(ou.node_timeout, 5.5)
|
|
|
|
self.assertTrue(ou.get_container_ring() is not None)
|
2010-07-12 17:03:45 -05:00
|
|
|
|
2017-03-21 20:10:12 +01:00
|
|
|
def test_conf_params(self):
|
|
|
|
# defaults
|
|
|
|
daemon = object_updater.ObjectUpdater({}, logger=self.logger)
|
|
|
|
self.assertEqual(daemon.devices, '/srv/node')
|
|
|
|
self.assertEqual(daemon.mount_check, True)
|
|
|
|
self.assertEqual(daemon.swift_dir, '/etc/swift')
|
|
|
|
self.assertEqual(daemon.interval, 300)
|
object-updater: add concurrent updates
The object updater now supports two configuration settings:
"concurrency" and "updater_workers". The latter controls how many
worker processes are spawned, while the former controls how many
concurrent container updates are performed by each worker
process. This should speed the processing of async_pendings.
There is a change to the semantics of the configuration
options. Previously, "concurrency" controlled the number of worker
processes spawned, and "updater_workers" did not exist. I switched the
meanings for consistency with other configuration options. In the
object reconstructor, object replicator, object server, object
expirer, container replicator, container server, account replicator,
account server, and account reaper, "concurrency" refers to the number
of concurrent tasks performed within one process (for reference, the
container updater and object auditor use "concurrency" to mean number
of processes).
On upgrade, a node configured with concurrency=N will still handle
async updates N-at-a-time, but will do so using only one process
instead of N.
UpgradeImpact:
If you have a config file like this:
[object-updater]
concurrency = <N>
and you want to take advantage of faster updates, then do this:
[object-updater]
concurrency = 8 # the default; you can omit this line
updater_workers = <N>
If you want updates to be processed exactly as before, do this:
[object-updater]
concurrency = 1
updater_workers = <N>
Change-Id: I17e18088e61f664e1b9942d66423666d0cae1689
2018-06-04 16:26:50 -07:00
|
|
|
self.assertEqual(daemon.concurrency, 8)
|
|
|
|
self.assertEqual(daemon.updater_workers, 1)
|
2017-03-21 20:10:12 +01:00
|
|
|
self.assertEqual(daemon.max_objects_per_second, 50.0)
|
|
|
|
|
|
|
|
# non-defaults
|
|
|
|
conf = {
|
|
|
|
'devices': '/some/where/else',
|
|
|
|
'mount_check': 'huh?',
|
|
|
|
'swift_dir': '/not/here',
|
|
|
|
'interval': '600',
|
|
|
|
'concurrency': '2',
|
object-updater: add concurrent updates
The object updater now supports two configuration settings:
"concurrency" and "updater_workers". The latter controls how many
worker processes are spawned, while the former controls how many
concurrent container updates are performed by each worker
process. This should speed the processing of async_pendings.
There is a change to the semantics of the configuration
options. Previously, "concurrency" controlled the number of worker
processes spawned, and "updater_workers" did not exist. I switched the
meanings for consistency with other configuration options. In the
object reconstructor, object replicator, object server, object
expirer, container replicator, container server, account replicator,
account server, and account reaper, "concurrency" refers to the number
of concurrent tasks performed within one process (for reference, the
container updater and object auditor use "concurrency" to mean number
of processes).
On upgrade, a node configured with concurrency=N will still handle
async updates N-at-a-time, but will do so using only one process
instead of N.
UpgradeImpact:
If you have a config file like this:
[object-updater]
concurrency = <N>
and you want to take advantage of faster updates, then do this:
[object-updater]
concurrency = 8 # the default; you can omit this line
updater_workers = <N>
If you want updates to be processed exactly as before, do this:
[object-updater]
concurrency = 1
updater_workers = <N>
Change-Id: I17e18088e61f664e1b9942d66423666d0cae1689
2018-06-04 16:26:50 -07:00
|
|
|
'updater_workers': '3',
|
2017-03-21 20:10:12 +01:00
|
|
|
'objects_per_second': '10.5',
|
|
|
|
}
|
|
|
|
daemon = object_updater.ObjectUpdater(conf, logger=self.logger)
|
|
|
|
self.assertEqual(daemon.devices, '/some/where/else')
|
|
|
|
self.assertEqual(daemon.mount_check, False)
|
|
|
|
self.assertEqual(daemon.swift_dir, '/not/here')
|
|
|
|
self.assertEqual(daemon.interval, 600)
|
|
|
|
self.assertEqual(daemon.concurrency, 2)
|
object-updater: add concurrent updates
The object updater now supports two configuration settings:
"concurrency" and "updater_workers". The latter controls how many
worker processes are spawned, while the former controls how many
concurrent container updates are performed by each worker
process. This should speed the processing of async_pendings.
There is a change to the semantics of the configuration
options. Previously, "concurrency" controlled the number of worker
processes spawned, and "updater_workers" did not exist. I switched the
meanings for consistency with other configuration options. In the
object reconstructor, object replicator, object server, object
expirer, container replicator, container server, account replicator,
account server, and account reaper, "concurrency" refers to the number
of concurrent tasks performed within one process (for reference, the
container updater and object auditor use "concurrency" to mean number
of processes).
On upgrade, a node configured with concurrency=N will still handle
async updates N-at-a-time, but will do so using only one process
instead of N.
UpgradeImpact:
If you have a config file like this:
[object-updater]
concurrency = <N>
and you want to take advantage of faster updates, then do this:
[object-updater]
concurrency = 8 # the default; you can omit this line
updater_workers = <N>
If you want updates to be processed exactly as before, do this:
[object-updater]
concurrency = 1
updater_workers = <N>
Change-Id: I17e18088e61f664e1b9942d66423666d0cae1689
2018-06-04 16:26:50 -07:00
|
|
|
self.assertEqual(daemon.updater_workers, 3)
|
2017-03-21 20:10:12 +01:00
|
|
|
self.assertEqual(daemon.max_objects_per_second, 10.5)
|
|
|
|
|
|
|
|
# check deprecated option
|
|
|
|
daemon = object_updater.ObjectUpdater({'slowdown': '0.04'},
|
|
|
|
logger=self.logger)
|
|
|
|
self.assertEqual(daemon.max_objects_per_second, 20.0)
|
|
|
|
|
|
|
|
def check_bad(conf):
|
|
|
|
with self.assertRaises(ValueError):
|
|
|
|
object_updater.ObjectUpdater(conf, logger=self.logger)
|
|
|
|
|
|
|
|
check_bad({'interval': 'foo'})
|
|
|
|
check_bad({'interval': '300.0'})
|
|
|
|
check_bad({'concurrency': 'bar'})
|
|
|
|
check_bad({'concurrency': '1.0'})
|
|
|
|
check_bad({'slowdown': 'baz'})
|
|
|
|
check_bad({'objects_per_second': 'quux'})
|
|
|
|
|
2014-10-02 14:10:04 -05:00
|
|
|
@mock.patch('os.listdir')
|
|
|
|
def test_listdir_with_exception(self, mock_listdir):
|
|
|
|
e = OSError('permission_denied')
|
|
|
|
mock_listdir.side_effect = e
|
|
|
|
# setup updater
|
|
|
|
conf = {
|
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'false',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
}
|
2017-09-01 14:15:45 -07:00
|
|
|
daemon = object_updater.ObjectUpdater(conf, logger=self.logger)
|
2014-10-02 14:10:04 -05:00
|
|
|
paths = daemon._listdir('foo/bar')
|
|
|
|
self.assertEqual([], paths)
|
2017-09-01 14:15:45 -07:00
|
|
|
log_lines = self.logger.get_lines_for_level('error')
|
2014-10-02 14:10:04 -05:00
|
|
|
msg = ('ERROR: Unable to access foo/bar: permission_denied')
|
|
|
|
self.assertEqual(log_lines[0], msg)
|
|
|
|
|
|
|
|
@mock.patch('os.listdir', return_value=['foo', 'bar'])
|
|
|
|
def test_listdir_without_exception(self, mock_listdir):
|
|
|
|
# setup updater
|
|
|
|
conf = {
|
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'false',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
}
|
2017-09-01 14:15:45 -07:00
|
|
|
daemon = object_updater.ObjectUpdater(conf, logger=self.logger)
|
2014-10-02 14:10:04 -05:00
|
|
|
path = daemon._listdir('foo/bar/')
|
2017-09-01 14:15:45 -07:00
|
|
|
log_lines = self.logger.get_lines_for_level('error')
|
2014-10-02 14:10:04 -05:00
|
|
|
self.assertEqual(len(log_lines), 0)
|
|
|
|
self.assertEqual(path, ['foo', 'bar'])
|
|
|
|
|
2011-04-20 19:54:28 +00:00
|
|
|
def test_object_sweep(self):
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
def check_with_idx(index, warn, should_skip):
|
|
|
|
if int(index) > 0:
|
|
|
|
asyncdir = os.path.join(self.sda1,
|
|
|
|
ASYNCDIR_BASE + "-" + index)
|
|
|
|
else:
|
|
|
|
asyncdir = os.path.join(self.sda1, ASYNCDIR_BASE)
|
2011-04-20 19:54:28 +00:00
|
|
|
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
prefix_dir = os.path.join(asyncdir, 'abc')
|
|
|
|
mkpath(prefix_dir)
|
2011-04-20 19:54:28 +00:00
|
|
|
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
# A non-directory where directory is expected should just be
|
|
|
|
# skipped, but should not stop processing of subsequent
|
|
|
|
# directories.
|
|
|
|
not_dirs = (
|
|
|
|
os.path.join(self.sda1, 'not_a_dir'),
|
|
|
|
os.path.join(self.sda1,
|
|
|
|
ASYNCDIR_BASE + '-' + 'twentington'),
|
|
|
|
os.path.join(self.sda1,
|
|
|
|
ASYNCDIR_BASE + '-' + str(int(index) + 100)))
|
2011-04-20 19:54:28 +00:00
|
|
|
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
for not_dir in not_dirs:
|
|
|
|
with open(not_dir, 'w'):
|
|
|
|
pass
|
2011-04-20 19:54:28 +00:00
|
|
|
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
objects = {
|
|
|
|
'a': [1089.3, 18.37, 12.83, 1.3],
|
|
|
|
'b': [49.4, 49.3, 49.2, 49.1],
|
|
|
|
'c': [109984.123],
|
|
|
|
}
|
|
|
|
|
|
|
|
expected = set()
|
2015-06-24 09:36:37 +02:00
|
|
|
for o, timestamps in objects.items():
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
ohash = hash_path('account', 'container', o)
|
|
|
|
for t in timestamps:
|
|
|
|
o_path = os.path.join(prefix_dir, ohash + '-' +
|
|
|
|
normalize_timestamp(t))
|
|
|
|
if t == timestamps[0]:
|
|
|
|
expected.add((o_path, int(index)))
|
|
|
|
write_pickle({}, o_path)
|
|
|
|
|
|
|
|
seen = set()
|
|
|
|
|
|
|
|
class MockObjectUpdater(object_updater.ObjectUpdater):
|
2015-03-17 08:32:57 +00:00
|
|
|
def process_object_update(self, update_path, device, policy):
|
|
|
|
seen.add((update_path, int(policy)))
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
os.unlink(update_path)
|
|
|
|
|
2016-12-01 19:58:08 +09:00
|
|
|
ou = MockObjectUpdater({
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'false',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
'interval': '1',
|
|
|
|
'concurrency': '1',
|
|
|
|
'node_timeout': '5'})
|
2016-12-01 19:58:08 +09:00
|
|
|
ou.logger = mock_logger = mock.MagicMock()
|
|
|
|
ou.object_sweep(self.sda1)
|
2015-08-02 22:47:42 +05:30
|
|
|
self.assertEqual(mock_logger.warning.call_count, warn)
|
2015-07-21 19:23:00 +05:30
|
|
|
self.assertTrue(
|
|
|
|
os.path.exists(os.path.join(self.sda1, 'not_a_dir')))
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
if should_skip:
|
|
|
|
# if we were supposed to skip over the dir, we didn't process
|
|
|
|
# anything at all
|
|
|
|
self.assertEqual(set(), seen)
|
|
|
|
else:
|
|
|
|
self.assertEqual(expected, seen)
|
|
|
|
|
|
|
|
# test cleanup: the tempdir gets cleaned up between runs, but this
|
|
|
|
# way we can be called multiple times in a single test method
|
|
|
|
for not_dir in not_dirs:
|
|
|
|
os.unlink(not_dir)
|
|
|
|
|
|
|
|
# first check with valid policies
|
|
|
|
for pol in POLICIES:
|
|
|
|
check_with_idx(str(pol.idx), 0, should_skip=False)
|
|
|
|
# now check with a bogus async dir policy and make sure we get
|
|
|
|
# a warning indicating that the '99' policy isn't valid
|
|
|
|
check_with_idx('99', 1, should_skip=True)
|
2011-04-20 19:54:28 +00:00
|
|
|
|
Improve object-updater's stats logging
The object updater has five different stats, but its logging only told
you two of them (successes and failures), and it only told you after
finishing all the async_pendings for a device. If you have a cluster
that's been sick and has millions upon millions of async_pendings
laying around, then your object-updaters are frustratingly
silent. I've seen one cluster with around 8 million async_pendings per
disk where the object-updaters only emitted stats every 12 hours.
Yes, if you have StatsD logging set up properly, you can go look at
your graphs and get real-time feedback on what it's doing. If you
don't have that, all you get is a frustrating silence.
Now, the object updater tells you all of its stats (successes,
failures, quarantines due to bad pickles, unlinks, and errors), and it
tells you incremental progress every five minutes. The logging at the
end of a pass remains and has been expanded to also include all stats.
Also included is a small change to what counts as an error: unmounted
drives no longer do. The goal is that only abnormal things count as
errors, like permission problems, malformed filenames, and so
on. These are things that should never happen, but if they do, may
require operator intervention. Drives fail, so logging an error upon
encountering an unmounted drive is not useful.
Change-Id: Idbddd507f0b633d14dffb7a9834fce93a10359ab
2018-01-12 07:17:18 -08:00
|
|
|
def test_sweep_logs(self):
|
|
|
|
asyncdir = os.path.join(self.sda1, ASYNCDIR_BASE)
|
|
|
|
prefix_dir = os.path.join(asyncdir, 'abc')
|
|
|
|
mkpath(prefix_dir)
|
|
|
|
|
|
|
|
for o, t in [('abc', 123), ('def', 234), ('ghi', 345),
|
|
|
|
('jkl', 456), ('mno', 567)]:
|
|
|
|
ohash = hash_path('account', 'container', o)
|
|
|
|
o_path = os.path.join(prefix_dir, ohash + '-' +
|
|
|
|
normalize_timestamp(t))
|
|
|
|
write_pickle({}, o_path)
|
|
|
|
|
|
|
|
class MockObjectUpdater(object_updater.ObjectUpdater):
|
|
|
|
def process_object_update(self, update_path, device, policy):
|
|
|
|
os.unlink(update_path)
|
|
|
|
self.stats.successes += 1
|
|
|
|
self.stats.unlinks += 1
|
|
|
|
|
|
|
|
logger = FakeLogger()
|
|
|
|
ou = MockObjectUpdater({
|
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'false',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
'interval': '1',
|
|
|
|
'concurrency': '1',
|
|
|
|
'report_interval': '10.0',
|
|
|
|
'node_timeout': '5'}, logger=logger)
|
|
|
|
|
|
|
|
now = [time()]
|
|
|
|
|
|
|
|
def mock_time_function():
|
|
|
|
rv = now[0]
|
|
|
|
now[0] += 5
|
|
|
|
return rv
|
|
|
|
|
|
|
|
# With 10s between updates, time() advancing 5s every time we look,
|
|
|
|
# and 5 async_pendings on disk, we should get at least two progress
|
|
|
|
# lines.
|
|
|
|
with mock.patch('swift.obj.updater.time',
|
object-updater: add concurrent updates
The object updater now supports two configuration settings:
"concurrency" and "updater_workers". The latter controls how many
worker processes are spawned, while the former controls how many
concurrent container updates are performed by each worker
process. This should speed the processing of async_pendings.
There is a change to the semantics of the configuration
options. Previously, "concurrency" controlled the number of worker
processes spawned, and "updater_workers" did not exist. I switched the
meanings for consistency with other configuration options. In the
object reconstructor, object replicator, object server, object
expirer, container replicator, container server, account replicator,
account server, and account reaper, "concurrency" refers to the number
of concurrent tasks performed within one process (for reference, the
container updater and object auditor use "concurrency" to mean number
of processes).
On upgrade, a node configured with concurrency=N will still handle
async updates N-at-a-time, but will do so using only one process
instead of N.
UpgradeImpact:
If you have a config file like this:
[object-updater]
concurrency = <N>
and you want to take advantage of faster updates, then do this:
[object-updater]
concurrency = 8 # the default; you can omit this line
updater_workers = <N>
If you want updates to be processed exactly as before, do this:
[object-updater]
concurrency = 1
updater_workers = <N>
Change-Id: I17e18088e61f664e1b9942d66423666d0cae1689
2018-06-04 16:26:50 -07:00
|
|
|
mock.MagicMock(time=mock_time_function)), \
|
|
|
|
mock.patch.object(object_updater, 'ContextPool', MockPool):
|
Improve object-updater's stats logging
The object updater has five different stats, but its logging only told
you two of them (successes and failures), and it only told you after
finishing all the async_pendings for a device. If you have a cluster
that's been sick and has millions upon millions of async_pendings
laying around, then your object-updaters are frustratingly
silent. I've seen one cluster with around 8 million async_pendings per
disk where the object-updaters only emitted stats every 12 hours.
Yes, if you have StatsD logging set up properly, you can go look at
your graphs and get real-time feedback on what it's doing. If you
don't have that, all you get is a frustrating silence.
Now, the object updater tells you all of its stats (successes,
failures, quarantines due to bad pickles, unlinks, and errors), and it
tells you incremental progress every five minutes. The logging at the
end of a pass remains and has been expanded to also include all stats.
Also included is a small change to what counts as an error: unmounted
drives no longer do. The goal is that only abnormal things count as
errors, like permission problems, malformed filenames, and so
on. These are things that should never happen, but if they do, may
require operator intervention. Drives fail, so logging an error upon
encountering an unmounted drive is not useful.
Change-Id: Idbddd507f0b633d14dffb7a9834fce93a10359ab
2018-01-12 07:17:18 -08:00
|
|
|
ou.object_sweep(self.sda1)
|
|
|
|
|
|
|
|
info_lines = logger.get_lines_for_level('info')
|
|
|
|
self.assertEqual(4, len(info_lines))
|
|
|
|
self.assertIn("sweep starting", info_lines[0])
|
|
|
|
self.assertIn(self.sda1, info_lines[0])
|
|
|
|
|
|
|
|
self.assertIn("sweep progress", info_lines[1])
|
|
|
|
# the space ensures it's a positive number
|
2018-01-16 17:03:38 -08:00
|
|
|
self.assertIn(
|
2018-05-02 10:21:11 +01:00
|
|
|
"2 successes, 0 failures, 0 quarantines, 2 unlinks, 0 errors, "
|
|
|
|
"0 redirects",
|
2018-01-16 17:03:38 -08:00
|
|
|
info_lines[1])
|
Improve object-updater's stats logging
The object updater has five different stats, but its logging only told
you two of them (successes and failures), and it only told you after
finishing all the async_pendings for a device. If you have a cluster
that's been sick and has millions upon millions of async_pendings
laying around, then your object-updaters are frustratingly
silent. I've seen one cluster with around 8 million async_pendings per
disk where the object-updaters only emitted stats every 12 hours.
Yes, if you have StatsD logging set up properly, you can go look at
your graphs and get real-time feedback on what it's doing. If you
don't have that, all you get is a frustrating silence.
Now, the object updater tells you all of its stats (successes,
failures, quarantines due to bad pickles, unlinks, and errors), and it
tells you incremental progress every five minutes. The logging at the
end of a pass remains and has been expanded to also include all stats.
Also included is a small change to what counts as an error: unmounted
drives no longer do. The goal is that only abnormal things count as
errors, like permission problems, malformed filenames, and so
on. These are things that should never happen, but if they do, may
require operator intervention. Drives fail, so logging an error upon
encountering an unmounted drive is not useful.
Change-Id: Idbddd507f0b633d14dffb7a9834fce93a10359ab
2018-01-12 07:17:18 -08:00
|
|
|
self.assertIn(self.sda1, info_lines[1])
|
|
|
|
|
|
|
|
self.assertIn("sweep progress", info_lines[2])
|
2018-01-16 17:03:38 -08:00
|
|
|
self.assertIn(
|
2018-05-02 10:21:11 +01:00
|
|
|
"4 successes, 0 failures, 0 quarantines, 4 unlinks, 0 errors, "
|
|
|
|
"0 redirects",
|
2018-01-16 17:03:38 -08:00
|
|
|
info_lines[2])
|
Improve object-updater's stats logging
The object updater has five different stats, but its logging only told
you two of them (successes and failures), and it only told you after
finishing all the async_pendings for a device. If you have a cluster
that's been sick and has millions upon millions of async_pendings
laying around, then your object-updaters are frustratingly
silent. I've seen one cluster with around 8 million async_pendings per
disk where the object-updaters only emitted stats every 12 hours.
Yes, if you have StatsD logging set up properly, you can go look at
your graphs and get real-time feedback on what it's doing. If you
don't have that, all you get is a frustrating silence.
Now, the object updater tells you all of its stats (successes,
failures, quarantines due to bad pickles, unlinks, and errors), and it
tells you incremental progress every five minutes. The logging at the
end of a pass remains and has been expanded to also include all stats.
Also included is a small change to what counts as an error: unmounted
drives no longer do. The goal is that only abnormal things count as
errors, like permission problems, malformed filenames, and so
on. These are things that should never happen, but if they do, may
require operator intervention. Drives fail, so logging an error upon
encountering an unmounted drive is not useful.
Change-Id: Idbddd507f0b633d14dffb7a9834fce93a10359ab
2018-01-12 07:17:18 -08:00
|
|
|
self.assertIn(self.sda1, info_lines[2])
|
|
|
|
|
|
|
|
self.assertIn("sweep complete", info_lines[3])
|
2018-01-16 17:03:38 -08:00
|
|
|
self.assertIn(
|
2018-05-02 10:21:11 +01:00
|
|
|
"5 successes, 0 failures, 0 quarantines, 5 unlinks, 0 errors, "
|
|
|
|
"0 redirects",
|
2018-01-16 17:03:38 -08:00
|
|
|
info_lines[3])
|
Improve object-updater's stats logging
The object updater has five different stats, but its logging only told
you two of them (successes and failures), and it only told you after
finishing all the async_pendings for a device. If you have a cluster
that's been sick and has millions upon millions of async_pendings
laying around, then your object-updaters are frustratingly
silent. I've seen one cluster with around 8 million async_pendings per
disk where the object-updaters only emitted stats every 12 hours.
Yes, if you have StatsD logging set up properly, you can go look at
your graphs and get real-time feedback on what it's doing. If you
don't have that, all you get is a frustrating silence.
Now, the object updater tells you all of its stats (successes,
failures, quarantines due to bad pickles, unlinks, and errors), and it
tells you incremental progress every five minutes. The logging at the
end of a pass remains and has been expanded to also include all stats.
Also included is a small change to what counts as an error: unmounted
drives no longer do. The goal is that only abnormal things count as
errors, like permission problems, malformed filenames, and so
on. These are things that should never happen, but if they do, may
require operator intervention. Drives fail, so logging an error upon
encountering an unmounted drive is not useful.
Change-Id: Idbddd507f0b633d14dffb7a9834fce93a10359ab
2018-01-12 07:17:18 -08:00
|
|
|
self.assertIn(self.sda1, info_lines[3])
|
|
|
|
|
2018-05-30 14:35:21 -07:00
|
|
|
def test_sweep_logs_multiple_policies(self):
|
|
|
|
for policy in _mocked_policies:
|
|
|
|
asyncdir = os.path.join(self.sda1, get_async_dir(policy.idx))
|
|
|
|
prefix_dir = os.path.join(asyncdir, 'abc')
|
|
|
|
mkpath(prefix_dir)
|
|
|
|
|
|
|
|
for o, t in [('abc', 123), ('def', 234), ('ghi', 345)]:
|
|
|
|
ohash = hash_path('account', 'container%d' % policy.idx, o)
|
|
|
|
o_path = os.path.join(prefix_dir, ohash + '-' +
|
|
|
|
normalize_timestamp(t))
|
|
|
|
write_pickle({}, o_path)
|
|
|
|
|
|
|
|
class MockObjectUpdater(object_updater.ObjectUpdater):
|
|
|
|
def process_object_update(self, update_path, device, policy):
|
|
|
|
os.unlink(update_path)
|
|
|
|
self.stats.successes += 1
|
|
|
|
self.stats.unlinks += 1
|
|
|
|
|
|
|
|
logger = FakeLogger()
|
|
|
|
ou = MockObjectUpdater({
|
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'false',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
'interval': '1',
|
|
|
|
'concurrency': '1',
|
|
|
|
'report_interval': '10.0',
|
|
|
|
'node_timeout': '5'}, logger=logger)
|
|
|
|
|
|
|
|
now = [time()]
|
|
|
|
|
|
|
|
def mock_time():
|
|
|
|
rv = now[0]
|
|
|
|
now[0] += 0.01
|
|
|
|
return rv
|
|
|
|
|
|
|
|
with mock.patch('swift.obj.updater.time',
|
|
|
|
mock.MagicMock(time=mock_time)):
|
|
|
|
ou.object_sweep(self.sda1)
|
|
|
|
|
|
|
|
completion_lines = [l for l in logger.get_lines_for_level('info')
|
|
|
|
if "sweep complete" in l]
|
|
|
|
|
|
|
|
self.assertEqual(len(completion_lines), 1)
|
|
|
|
self.assertIn("sweep complete", completion_lines[0])
|
|
|
|
self.assertIn(
|
|
|
|
"6 successes, 0 failures, 0 quarantines, 6 unlinks, 0 errors, "
|
|
|
|
"0 redirects",
|
|
|
|
completion_lines[0])
|
|
|
|
|
2017-09-01 14:15:45 -07:00
|
|
|
@mock.patch.object(object_updater, 'check_drive')
|
|
|
|
def test_run_once_with_disk_unmounted(self, mock_check_drive):
|
2017-09-15 06:15:40 +00:00
|
|
|
mock_check_drive.side_effect = ValueError
|
2016-12-01 19:58:08 +09:00
|
|
|
ou = object_updater.ObjectUpdater({
|
2010-08-20 00:42:38 +00:00
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'false',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
'interval': '1',
|
|
|
|
'concurrency': '1',
|
2012-10-18 14:49:46 -07:00
|
|
|
'node_timeout': '15'})
|
2016-12-01 19:58:08 +09:00
|
|
|
ou.run_once()
|
2015-03-17 08:32:57 +00:00
|
|
|
async_dir = os.path.join(self.sda1, get_async_dir(POLICIES[0]))
|
2010-07-12 17:03:45 -05:00
|
|
|
os.mkdir(async_dir)
|
2016-12-01 19:58:08 +09:00
|
|
|
ou.run_once()
|
2015-07-21 19:23:00 +05:30
|
|
|
self.assertTrue(os.path.exists(async_dir))
|
2017-09-01 14:15:45 -07:00
|
|
|
# each run calls check_device
|
|
|
|
self.assertEqual([
|
|
|
|
mock.call(self.devices_dir, 'sda1', False),
|
|
|
|
mock.call(self.devices_dir, 'sda1', False),
|
|
|
|
], mock_check_drive.mock_calls)
|
|
|
|
mock_check_drive.reset_mock()
|
2010-07-12 17:03:45 -05:00
|
|
|
|
2016-12-01 19:58:08 +09:00
|
|
|
ou = object_updater.ObjectUpdater({
|
2013-11-26 15:08:13 -05:00
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'TrUe',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
'interval': '1',
|
|
|
|
'concurrency': '1',
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
'node_timeout': '15'}, logger=self.logger)
|
|
|
|
odd_dir = os.path.join(async_dir, 'not really supposed '
|
|
|
|
'to be here')
|
2013-11-26 15:08:13 -05:00
|
|
|
os.mkdir(odd_dir)
|
2016-12-01 19:58:08 +09:00
|
|
|
ou.run_once()
|
2015-07-21 19:23:00 +05:30
|
|
|
self.assertTrue(os.path.exists(async_dir))
|
|
|
|
self.assertTrue(os.path.exists(odd_dir)) # skipped - not mounted!
|
2013-11-26 15:08:13 -05:00
|
|
|
self.assertEqual([
|
2017-09-01 14:15:45 -07:00
|
|
|
mock.call(self.devices_dir, 'sda1', True),
|
|
|
|
], mock_check_drive.mock_calls)
|
Improve object-updater's stats logging
The object updater has five different stats, but its logging only told
you two of them (successes and failures), and it only told you after
finishing all the async_pendings for a device. If you have a cluster
that's been sick and has millions upon millions of async_pendings
laying around, then your object-updaters are frustratingly
silent. I've seen one cluster with around 8 million async_pendings per
disk where the object-updaters only emitted stats every 12 hours.
Yes, if you have StatsD logging set up properly, you can go look at
your graphs and get real-time feedback on what it's doing. If you
don't have that, all you get is a frustrating silence.
Now, the object updater tells you all of its stats (successes,
failures, quarantines due to bad pickles, unlinks, and errors), and it
tells you incremental progress every five minutes. The logging at the
end of a pass remains and has been expanded to also include all stats.
Also included is a small change to what counts as an error: unmounted
drives no longer do. The goal is that only abnormal things count as
errors, like permission problems, malformed filenames, and so
on. These are things that should never happen, but if they do, may
require operator intervention. Drives fail, so logging an error upon
encountering an unmounted drive is not useful.
Change-Id: Idbddd507f0b633d14dffb7a9834fce93a10359ab
2018-01-12 07:17:18 -08:00
|
|
|
self.assertEqual(ou.logger.get_increment_counts(), {})
|
2013-11-26 15:08:13 -05:00
|
|
|
|
2017-09-01 14:15:45 -07:00
|
|
|
@mock.patch.object(object_updater, 'check_drive')
|
|
|
|
def test_run_once(self, mock_check_drive):
|
2017-09-15 06:15:40 +00:00
|
|
|
mock_check_drive.side_effect = lambda r, d, mc: os.path.join(r, d)
|
2016-12-01 19:58:08 +09:00
|
|
|
ou = object_updater.ObjectUpdater({
|
2013-11-26 15:08:13 -05:00
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'false',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
'interval': '1',
|
|
|
|
'concurrency': '1',
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
'node_timeout': '15'}, logger=self.logger)
|
2016-12-01 19:58:08 +09:00
|
|
|
ou.run_once()
|
2015-03-17 08:32:57 +00:00
|
|
|
async_dir = os.path.join(self.sda1, get_async_dir(POLICIES[0]))
|
2013-11-26 15:08:13 -05:00
|
|
|
os.mkdir(async_dir)
|
2016-12-01 19:58:08 +09:00
|
|
|
ou.run_once()
|
2015-07-21 19:23:00 +05:30
|
|
|
self.assertTrue(os.path.exists(async_dir))
|
2017-09-01 14:15:45 -07:00
|
|
|
# each run calls check_device
|
|
|
|
self.assertEqual([
|
|
|
|
mock.call(self.devices_dir, 'sda1', False),
|
|
|
|
mock.call(self.devices_dir, 'sda1', False),
|
|
|
|
], mock_check_drive.mock_calls)
|
|
|
|
mock_check_drive.reset_mock()
|
2013-11-26 15:08:13 -05:00
|
|
|
|
2016-12-01 19:58:08 +09:00
|
|
|
ou = object_updater.ObjectUpdater({
|
2013-11-26 15:08:13 -05:00
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'TrUe',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
'interval': '1',
|
|
|
|
'concurrency': '1',
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
'node_timeout': '15'}, logger=self.logger)
|
|
|
|
odd_dir = os.path.join(async_dir, 'not really supposed '
|
|
|
|
'to be here')
|
2010-07-12 17:03:45 -05:00
|
|
|
os.mkdir(odd_dir)
|
2016-12-01 19:58:08 +09:00
|
|
|
ou.run_once()
|
2015-07-21 19:23:00 +05:30
|
|
|
self.assertTrue(os.path.exists(async_dir))
|
2013-11-26 15:08:13 -05:00
|
|
|
self.assertEqual([
|
2017-09-01 14:15:45 -07:00
|
|
|
mock.call(self.devices_dir, 'sda1', True),
|
|
|
|
], mock_check_drive.mock_calls)
|
2010-07-12 17:03:45 -05:00
|
|
|
|
|
|
|
ohash = hash_path('a', 'c', 'o')
|
|
|
|
odir = os.path.join(async_dir, ohash[-3:])
|
|
|
|
mkdirs(odir)
|
2012-10-18 14:49:46 -07:00
|
|
|
older_op_path = os.path.join(
|
|
|
|
odir,
|
|
|
|
'%s-%s' % (ohash, normalize_timestamp(time() - 1)))
|
|
|
|
op_path = os.path.join(
|
|
|
|
odir,
|
2010-07-12 17:03:45 -05:00
|
|
|
'%s-%s' % (ohash, normalize_timestamp(time())))
|
2012-10-18 14:49:46 -07:00
|
|
|
for path in (op_path, older_op_path):
|
|
|
|
with open(path, 'wb') as async_pending:
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
pickle.dump({'op': 'PUT', 'account': 'a',
|
|
|
|
'container': 'c',
|
2012-10-18 14:49:46 -07:00
|
|
|
'obj': 'o', 'headers': {
|
2013-11-26 15:08:13 -05:00
|
|
|
'X-Container-Timestamp':
|
|
|
|
normalize_timestamp(0)}},
|
2012-10-18 14:49:46 -07:00
|
|
|
async_pending)
|
2016-12-01 19:58:08 +09:00
|
|
|
ou.run_once()
|
2015-07-21 19:23:00 +05:30
|
|
|
self.assertTrue(not os.path.exists(older_op_path))
|
|
|
|
self.assertTrue(os.path.exists(op_path))
|
2016-12-01 19:58:08 +09:00
|
|
|
self.assertEqual(ou.logger.get_increment_counts(),
|
2012-10-18 14:49:46 -07:00
|
|
|
{'failures': 1, 'unlinks': 1})
|
2019-02-25 14:00:45 -08:00
|
|
|
self.assertIsNone(pickle.load(open(op_path, 'rb')).get('successes'))
|
2010-07-12 17:03:45 -05:00
|
|
|
|
2017-05-11 01:39:14 -06:00
|
|
|
bindsock = listen_zero()
|
2011-04-20 19:54:28 +00:00
|
|
|
|
2010-08-26 09:03:08 -07:00
|
|
|
def accepter(sock, return_code):
|
2010-07-12 17:03:45 -05:00
|
|
|
try:
|
|
|
|
with Timeout(3):
|
|
|
|
inc = sock.makefile('rb')
|
|
|
|
out = sock.makefile('wb')
|
2019-02-25 14:00:45 -08:00
|
|
|
out.write(b'HTTP/1.1 %d OK\r\nContent-Length: 0\r\n\r\n' %
|
2010-07-12 17:03:45 -05:00
|
|
|
return_code)
|
|
|
|
out.flush()
|
2015-08-06 00:55:36 +05:30
|
|
|
self.assertEqual(inc.readline(),
|
2019-02-25 14:00:45 -08:00
|
|
|
b'PUT /sda1/0/a/c/o HTTP/1.1\r\n')
|
2016-03-02 10:28:51 +00:00
|
|
|
headers = HeaderKeyDict()
|
2019-07-25 10:56:53 -07:00
|
|
|
line = bytes_to_wsgi(inc.readline())
|
|
|
|
while line and line != '\r\n':
|
|
|
|
headers[line.split(':')[0]] = \
|
|
|
|
line.split(':')[1].strip()
|
|
|
|
line = bytes_to_wsgi(inc.readline())
|
|
|
|
self.assertIn('x-container-timestamp', headers)
|
|
|
|
self.assertIn('X-Backend-Storage-Policy-Index',
|
2019-02-25 14:00:45 -08:00
|
|
|
headers)
|
2013-08-28 21:16:08 +02:00
|
|
|
except BaseException as err:
|
2010-07-12 17:03:45 -05:00
|
|
|
return err
|
|
|
|
return None
|
2011-04-20 19:54:28 +00:00
|
|
|
|
2010-09-21 20:31:14 +00:00
|
|
|
def accept(return_codes):
|
2010-08-26 09:03:08 -07:00
|
|
|
try:
|
|
|
|
events = []
|
2016-12-01 19:51:05 +09:00
|
|
|
for code in return_codes:
|
2010-08-26 09:03:08 -07:00
|
|
|
with Timeout(3):
|
|
|
|
sock, addr = bindsock.accept()
|
2010-09-21 20:31:14 +00:00
|
|
|
events.append(
|
2016-12-01 19:51:05 +09:00
|
|
|
spawn(accepter, sock, code))
|
2010-08-26 09:03:08 -07:00
|
|
|
for event in events:
|
|
|
|
err = event.wait()
|
|
|
|
if err:
|
|
|
|
raise err
|
2013-08-28 21:16:08 +02:00
|
|
|
except BaseException as err:
|
2010-08-26 09:03:08 -07:00
|
|
|
return err
|
|
|
|
return None
|
2012-10-18 14:49:46 -07:00
|
|
|
|
2013-11-26 15:08:13 -05:00
|
|
|
event = spawn(accept, [201, 500, 500])
|
2016-12-01 19:58:08 +09:00
|
|
|
for dev in ou.get_container_ring().devs:
|
2010-07-12 17:03:45 -05:00
|
|
|
if dev is not None:
|
|
|
|
dev['port'] = bindsock.getsockname()[1]
|
2012-10-18 14:49:46 -07:00
|
|
|
|
2016-12-01 19:58:08 +09:00
|
|
|
ou.logger._clear()
|
|
|
|
ou.run_once()
|
2010-08-26 09:03:08 -07:00
|
|
|
err = event.wait()
|
2010-09-21 20:31:14 +00:00
|
|
|
if err:
|
|
|
|
raise err
|
2015-07-21 19:23:00 +05:30
|
|
|
self.assertTrue(os.path.exists(op_path))
|
2016-12-01 19:58:08 +09:00
|
|
|
self.assertEqual(ou.logger.get_increment_counts(),
|
2012-10-18 14:49:46 -07:00
|
|
|
{'failures': 1})
|
2013-11-26 15:08:13 -05:00
|
|
|
self.assertEqual([0],
|
2019-02-25 14:00:45 -08:00
|
|
|
pickle.load(open(op_path, 'rb')).get('successes'))
|
2013-11-26 15:08:13 -05:00
|
|
|
|
2016-09-30 02:08:25 +09:00
|
|
|
event = spawn(accept, [404, 201])
|
2016-12-01 19:58:08 +09:00
|
|
|
ou.logger._clear()
|
|
|
|
ou.run_once()
|
2013-11-26 15:08:13 -05:00
|
|
|
err = event.wait()
|
|
|
|
if err:
|
|
|
|
raise err
|
2015-07-21 19:23:00 +05:30
|
|
|
self.assertTrue(os.path.exists(op_path))
|
2016-12-01 19:58:08 +09:00
|
|
|
self.assertEqual(ou.logger.get_increment_counts(),
|
2013-11-26 15:08:13 -05:00
|
|
|
{'failures': 1})
|
2016-09-30 02:08:25 +09:00
|
|
|
self.assertEqual([0, 2],
|
2019-02-25 14:00:45 -08:00
|
|
|
pickle.load(open(op_path, 'rb')).get('successes'))
|
2012-10-18 14:49:46 -07:00
|
|
|
|
2010-09-21 20:31:14 +00:00
|
|
|
event = spawn(accept, [201])
|
2016-12-01 19:58:08 +09:00
|
|
|
ou.logger._clear()
|
|
|
|
ou.run_once()
|
2010-09-21 20:31:14 +00:00
|
|
|
err = event.wait()
|
2010-08-26 09:03:08 -07:00
|
|
|
if err:
|
|
|
|
raise err
|
object-updater: add concurrent updates
The object updater now supports two configuration settings:
"concurrency" and "updater_workers". The latter controls how many
worker processes are spawned, while the former controls how many
concurrent container updates are performed by each worker
process. This should speed the processing of async_pendings.
There is a change to the semantics of the configuration
options. Previously, "concurrency" controlled the number of worker
processes spawned, and "updater_workers" did not exist. I switched the
meanings for consistency with other configuration options. In the
object reconstructor, object replicator, object server, object
expirer, container replicator, container server, account replicator,
account server, and account reaper, "concurrency" refers to the number
of concurrent tasks performed within one process (for reference, the
container updater and object auditor use "concurrency" to mean number
of processes).
On upgrade, a node configured with concurrency=N will still handle
async updates N-at-a-time, but will do so using only one process
instead of N.
UpgradeImpact:
If you have a config file like this:
[object-updater]
concurrency = <N>
and you want to take advantage of faster updates, then do this:
[object-updater]
concurrency = 8 # the default; you can omit this line
updater_workers = <N>
If you want updates to be processed exactly as before, do this:
[object-updater]
concurrency = 1
updater_workers = <N>
Change-Id: I17e18088e61f664e1b9942d66423666d0cae1689
2018-06-04 16:26:50 -07:00
|
|
|
|
|
|
|
# we remove the async_pending and its containing suffix dir, but not
|
|
|
|
# anything above that
|
|
|
|
self.assertFalse(os.path.exists(op_path))
|
|
|
|
self.assertFalse(os.path.exists(os.path.dirname(op_path)))
|
|
|
|
self.assertTrue(os.path.exists(os.path.dirname(os.path.dirname(
|
|
|
|
op_path))))
|
2016-12-01 19:58:08 +09:00
|
|
|
self.assertEqual(ou.logger.get_increment_counts(),
|
2012-10-18 14:49:46 -07:00
|
|
|
{'unlinks': 1, 'successes': 1})
|
|
|
|
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
def test_obj_put_legacy_updates(self):
|
|
|
|
ts = (normalize_timestamp(t) for t in
|
|
|
|
itertools.count(int(time())))
|
|
|
|
policy = POLICIES.get_by_index(0)
|
|
|
|
# setup updater
|
|
|
|
conf = {
|
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'false',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
}
|
2015-03-17 08:32:57 +00:00
|
|
|
async_dir = os.path.join(self.sda1, get_async_dir(policy))
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
os.mkdir(async_dir)
|
|
|
|
|
|
|
|
account, container, obj = 'a', 'c', 'o'
|
|
|
|
# write an async
|
|
|
|
for op in ('PUT', 'DELETE'):
|
|
|
|
self.logger._clear()
|
|
|
|
daemon = object_updater.ObjectUpdater(conf, logger=self.logger)
|
|
|
|
dfmanager = DiskFileManager(conf, daemon.logger)
|
|
|
|
# don't include storage-policy-index in headers_out pickle
|
2016-03-02 10:28:51 +00:00
|
|
|
headers_out = HeaderKeyDict({
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
'x-size': 0,
|
|
|
|
'x-content-type': 'text/plain',
|
|
|
|
'x-etag': 'd41d8cd98f00b204e9800998ecf8427e',
|
2015-06-15 22:10:45 +05:30
|
|
|
'x-timestamp': next(ts),
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
})
|
|
|
|
data = {'op': op, 'account': account, 'container': container,
|
|
|
|
'obj': obj, 'headers': headers_out}
|
|
|
|
dfmanager.pickle_async_update(self.sda1, account, container, obj,
|
2015-06-15 22:10:45 +05:30
|
|
|
data, next(ts), policy)
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
|
|
|
|
request_log = []
|
|
|
|
|
|
|
|
def capture(*args, **kwargs):
|
|
|
|
request_log.append((args, kwargs))
|
|
|
|
|
|
|
|
# run once
|
|
|
|
fake_status_codes = [200, 200, 200]
|
|
|
|
with mocked_http_conn(*fake_status_codes, give_connect=capture):
|
|
|
|
daemon.run_once()
|
|
|
|
self.assertEqual(len(fake_status_codes), len(request_log))
|
|
|
|
for request_args, request_kwargs in request_log:
|
|
|
|
ip, part, method, path, headers, qs, ssl = request_args
|
|
|
|
self.assertEqual(method, op)
|
2014-06-23 12:52:50 -07:00
|
|
|
self.assertEqual(headers['X-Backend-Storage-Policy-Index'],
|
2015-03-17 08:32:57 +00:00
|
|
|
str(int(policy)))
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
self.assertEqual(daemon.logger.get_increment_counts(),
|
|
|
|
{'successes': 1, 'unlinks': 1,
|
|
|
|
'async_pendings': 1})
|
|
|
|
|
2018-05-02 10:21:11 +01:00
|
|
|
def _write_async_update(self, dfmanager, timestamp, policy,
|
|
|
|
headers=None, container_path=None):
|
|
|
|
# write an async
|
|
|
|
account, container, obj = 'a', 'c', 'o'
|
|
|
|
op = 'PUT'
|
|
|
|
headers_out = headers or {
|
|
|
|
'x-size': 0,
|
|
|
|
'x-content-type': 'text/plain',
|
|
|
|
'x-etag': 'd41d8cd98f00b204e9800998ecf8427e',
|
|
|
|
'x-timestamp': timestamp.internal,
|
|
|
|
'X-Backend-Storage-Policy-Index': int(policy),
|
|
|
|
'User-Agent': 'object-server %s' % os.getpid()
|
|
|
|
}
|
|
|
|
data = {'op': op, 'account': account, 'container': container,
|
|
|
|
'obj': obj, 'headers': headers_out}
|
|
|
|
if container_path:
|
|
|
|
data['container_path'] = container_path
|
|
|
|
dfmanager.pickle_async_update(self.sda1, account, container, obj,
|
|
|
|
data, timestamp, policy)
|
|
|
|
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
def test_obj_put_async_updates(self):
|
2016-11-16 18:18:44 +00:00
|
|
|
ts_iter = make_timestamp_iter()
|
|
|
|
policies = list(POLICIES)
|
|
|
|
random.shuffle(policies)
|
|
|
|
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
# setup updater
|
|
|
|
conf = {
|
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'false',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
}
|
|
|
|
daemon = object_updater.ObjectUpdater(conf, logger=self.logger)
|
2016-11-16 18:18:44 +00:00
|
|
|
async_dir = os.path.join(self.sda1, get_async_dir(policies[0]))
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
os.mkdir(async_dir)
|
|
|
|
|
2018-05-02 10:21:11 +01:00
|
|
|
def do_test(headers_out, expected, container_path=None):
|
2016-11-16 18:18:44 +00:00
|
|
|
# write an async
|
|
|
|
dfmanager = DiskFileManager(conf, daemon.logger)
|
2018-05-02 10:21:11 +01:00
|
|
|
self._write_async_update(dfmanager, next(ts_iter), policies[0],
|
|
|
|
headers=headers_out,
|
|
|
|
container_path=container_path)
|
2016-11-16 18:18:44 +00:00
|
|
|
request_log = []
|
|
|
|
|
|
|
|
def capture(*args, **kwargs):
|
|
|
|
request_log.append((args, kwargs))
|
|
|
|
|
|
|
|
# run once
|
|
|
|
fake_status_codes = [
|
|
|
|
200, # object update success
|
|
|
|
200, # object update success
|
|
|
|
200, # object update conflict
|
|
|
|
]
|
|
|
|
with mocked_http_conn(*fake_status_codes, give_connect=capture):
|
|
|
|
daemon.run_once()
|
|
|
|
self.assertEqual(len(fake_status_codes), len(request_log))
|
|
|
|
for request_args, request_kwargs in request_log:
|
|
|
|
ip, part, method, path, headers, qs, ssl = request_args
|
|
|
|
self.assertEqual(method, 'PUT')
|
|
|
|
self.assertDictEqual(expected, headers)
|
|
|
|
self.assertEqual(
|
|
|
|
daemon.logger.get_increment_counts(),
|
|
|
|
{'successes': 1, 'unlinks': 1, 'async_pendings': 1})
|
|
|
|
self.assertFalse(os.listdir(async_dir))
|
|
|
|
daemon.logger.clear()
|
|
|
|
|
|
|
|
ts = next(ts_iter)
|
|
|
|
# use a dict rather than HeaderKeyDict so we can vary the case of the
|
|
|
|
# pickled headers
|
|
|
|
headers_out = {
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
'x-size': 0,
|
|
|
|
'x-content-type': 'text/plain',
|
|
|
|
'x-etag': 'd41d8cd98f00b204e9800998ecf8427e',
|
2016-11-16 18:18:44 +00:00
|
|
|
'x-timestamp': ts.normal,
|
|
|
|
'X-Backend-Storage-Policy-Index': int(policies[0]),
|
|
|
|
'User-Agent': 'object-server %s' % os.getpid()
|
|
|
|
}
|
|
|
|
expected = {
|
|
|
|
'X-Size': '0',
|
|
|
|
'X-Content-Type': 'text/plain',
|
|
|
|
'X-Etag': 'd41d8cd98f00b204e9800998ecf8427e',
|
|
|
|
'X-Timestamp': ts.normal,
|
|
|
|
'X-Backend-Storage-Policy-Index': str(int(policies[0])),
|
2018-05-02 10:21:11 +01:00
|
|
|
'User-Agent': 'object-updater %s' % os.getpid(),
|
|
|
|
'X-Backend-Accept-Redirect': 'true',
|
sharding: Better-handle newlines in container names
Previously, if you were on Python 2.7.10+ [0], such a newline would cause the
sharder to fail, complaining about invalid header values when trying to create
the shard containers. On older versions of Python, it would most likely cause a
parsing error in the container-server that was trying to handle the PUT.
Now, quote all places that we pass around container paths. This includes:
* The X-Container-Sysmeta-Shard-(Quoted-)Root sent when creating the (empty)
remote shards
* The X-Container-Sysmeta-Shard-(Quoted-)Root included when initializing the
local handoff for cleaving
* The X-Backend-(Quoted-)Container-Path the proxy sends to the object-server
for container updates
* The Location header the container-server sends to the object-updater
Note that a new header was required in requests so that servers would
know whether the value should be unquoted or not. We can get away with
reusing Location in responses by having clients opt-in to quoting with
a new X-Backend-Accept-Quoted-Location header.
During a rolling upgrade,
* old object-servers servicing requests from new proxy-servers will
not know about the container path override and so will try to update
the root container,
* in general, object updates are more likely to land in the root
container; the sharder will deal with them as misplaced objects, and
* shard containers created by new code on servers running old code
will think they are root containers until the server is running new
code, too; during this time they'll fail the sharder audit and report
stats to their account, but both of these should get cleared up upon
upgrade.
Drive-by: fix a "conainer_name" typo that prevented us from testing that
we can shard a container with unicode in its name. Also, add more UTF8
probe tests.
[0] See https://bugs.python.org/issue22928
Change-Id: Ie08f36e31a448a547468dd85911c3a3bc30e89f1
Closes-Bug: 1856894
2019-12-18 15:14:00 -08:00
|
|
|
'X-Backend-Accept-Quoted-Location': 'true',
|
2016-11-16 18:18:44 +00:00
|
|
|
}
|
sharding: Better-handle newlines in container names
Previously, if you were on Python 2.7.10+ [0], such a newline would cause the
sharder to fail, complaining about invalid header values when trying to create
the shard containers. On older versions of Python, it would most likely cause a
parsing error in the container-server that was trying to handle the PUT.
Now, quote all places that we pass around container paths. This includes:
* The X-Container-Sysmeta-Shard-(Quoted-)Root sent when creating the (empty)
remote shards
* The X-Container-Sysmeta-Shard-(Quoted-)Root included when initializing the
local handoff for cleaving
* The X-Backend-(Quoted-)Container-Path the proxy sends to the object-server
for container updates
* The Location header the container-server sends to the object-updater
Note that a new header was required in requests so that servers would
know whether the value should be unquoted or not. We can get away with
reusing Location in responses by having clients opt-in to quoting with
a new X-Backend-Accept-Quoted-Location header.
During a rolling upgrade,
* old object-servers servicing requests from new proxy-servers will
not know about the container path override and so will try to update
the root container,
* in general, object updates are more likely to land in the root
container; the sharder will deal with them as misplaced objects, and
* shard containers created by new code on servers running old code
will think they are root containers until the server is running new
code, too; during this time they'll fail the sharder audit and report
stats to their account, but both of these should get cleared up upon
upgrade.
Drive-by: fix a "conainer_name" typo that prevented us from testing that
we can shard a container with unicode in its name. Also, add more UTF8
probe tests.
[0] See https://bugs.python.org/issue22928
Change-Id: Ie08f36e31a448a547468dd85911c3a3bc30e89f1
Closes-Bug: 1856894
2019-12-18 15:14:00 -08:00
|
|
|
# always expect X-Backend-Accept-Redirect and
|
|
|
|
# X-Backend-Accept-Quoted-Location to be true
|
2018-05-02 10:21:11 +01:00
|
|
|
do_test(headers_out, expected, container_path='.shards_a/shard_c')
|
2016-11-16 18:18:44 +00:00
|
|
|
do_test(headers_out, expected)
|
|
|
|
|
sharding: Better-handle newlines in container names
Previously, if you were on Python 2.7.10+ [0], such a newline would cause the
sharder to fail, complaining about invalid header values when trying to create
the shard containers. On older versions of Python, it would most likely cause a
parsing error in the container-server that was trying to handle the PUT.
Now, quote all places that we pass around container paths. This includes:
* The X-Container-Sysmeta-Shard-(Quoted-)Root sent when creating the (empty)
remote shards
* The X-Container-Sysmeta-Shard-(Quoted-)Root included when initializing the
local handoff for cleaving
* The X-Backend-(Quoted-)Container-Path the proxy sends to the object-server
for container updates
* The Location header the container-server sends to the object-updater
Note that a new header was required in requests so that servers would
know whether the value should be unquoted or not. We can get away with
reusing Location in responses by having clients opt-in to quoting with
a new X-Backend-Accept-Quoted-Location header.
During a rolling upgrade,
* old object-servers servicing requests from new proxy-servers will
not know about the container path override and so will try to update
the root container,
* in general, object updates are more likely to land in the root
container; the sharder will deal with them as misplaced objects, and
* shard containers created by new code on servers running old code
will think they are root containers until the server is running new
code, too; during this time they'll fail the sharder audit and report
stats to their account, but both of these should get cleared up upon
upgrade.
Drive-by: fix a "conainer_name" typo that prevented us from testing that
we can shard a container with unicode in its name. Also, add more UTF8
probe tests.
[0] See https://bugs.python.org/issue22928
Change-Id: Ie08f36e31a448a547468dd85911c3a3bc30e89f1
Closes-Bug: 1856894
2019-12-18 15:14:00 -08:00
|
|
|
# ...unless they're already set
|
2018-05-02 10:21:11 +01:00
|
|
|
expected['X-Backend-Accept-Redirect'] = 'false'
|
sharding: Better-handle newlines in container names
Previously, if you were on Python 2.7.10+ [0], such a newline would cause the
sharder to fail, complaining about invalid header values when trying to create
the shard containers. On older versions of Python, it would most likely cause a
parsing error in the container-server that was trying to handle the PUT.
Now, quote all places that we pass around container paths. This includes:
* The X-Container-Sysmeta-Shard-(Quoted-)Root sent when creating the (empty)
remote shards
* The X-Container-Sysmeta-Shard-(Quoted-)Root included when initializing the
local handoff for cleaving
* The X-Backend-(Quoted-)Container-Path the proxy sends to the object-server
for container updates
* The Location header the container-server sends to the object-updater
Note that a new header was required in requests so that servers would
know whether the value should be unquoted or not. We can get away with
reusing Location in responses by having clients opt-in to quoting with
a new X-Backend-Accept-Quoted-Location header.
During a rolling upgrade,
* old object-servers servicing requests from new proxy-servers will
not know about the container path override and so will try to update
the root container,
* in general, object updates are more likely to land in the root
container; the sharder will deal with them as misplaced objects, and
* shard containers created by new code on servers running old code
will think they are root containers until the server is running new
code, too; during this time they'll fail the sharder audit and report
stats to their account, but both of these should get cleared up upon
upgrade.
Drive-by: fix a "conainer_name" typo that prevented us from testing that
we can shard a container with unicode in its name. Also, add more UTF8
probe tests.
[0] See https://bugs.python.org/issue22928
Change-Id: Ie08f36e31a448a547468dd85911c3a3bc30e89f1
Closes-Bug: 1856894
2019-12-18 15:14:00 -08:00
|
|
|
expected['X-Backend-Accept-Quoted-Location'] = 'false'
|
2018-05-02 10:21:11 +01:00
|
|
|
headers_out_2 = dict(headers_out)
|
|
|
|
headers_out_2['X-Backend-Accept-Redirect'] = 'false'
|
sharding: Better-handle newlines in container names
Previously, if you were on Python 2.7.10+ [0], such a newline would cause the
sharder to fail, complaining about invalid header values when trying to create
the shard containers. On older versions of Python, it would most likely cause a
parsing error in the container-server that was trying to handle the PUT.
Now, quote all places that we pass around container paths. This includes:
* The X-Container-Sysmeta-Shard-(Quoted-)Root sent when creating the (empty)
remote shards
* The X-Container-Sysmeta-Shard-(Quoted-)Root included when initializing the
local handoff for cleaving
* The X-Backend-(Quoted-)Container-Path the proxy sends to the object-server
for container updates
* The Location header the container-server sends to the object-updater
Note that a new header was required in requests so that servers would
know whether the value should be unquoted or not. We can get away with
reusing Location in responses by having clients opt-in to quoting with
a new X-Backend-Accept-Quoted-Location header.
During a rolling upgrade,
* old object-servers servicing requests from new proxy-servers will
not know about the container path override and so will try to update
the root container,
* in general, object updates are more likely to land in the root
container; the sharder will deal with them as misplaced objects, and
* shard containers created by new code on servers running old code
will think they are root containers until the server is running new
code, too; during this time they'll fail the sharder audit and report
stats to their account, but both of these should get cleared up upon
upgrade.
Drive-by: fix a "conainer_name" typo that prevented us from testing that
we can shard a container with unicode in its name. Also, add more UTF8
probe tests.
[0] See https://bugs.python.org/issue22928
Change-Id: Ie08f36e31a448a547468dd85911c3a3bc30e89f1
Closes-Bug: 1856894
2019-12-18 15:14:00 -08:00
|
|
|
headers_out_2['X-Backend-Accept-Quoted-Location'] = 'false'
|
2018-05-02 10:21:11 +01:00
|
|
|
do_test(headers_out_2, expected)
|
|
|
|
|
2016-11-16 18:18:44 +00:00
|
|
|
# updater should add policy header if missing
|
2018-05-02 10:21:11 +01:00
|
|
|
expected['X-Backend-Accept-Redirect'] = 'true'
|
sharding: Better-handle newlines in container names
Previously, if you were on Python 2.7.10+ [0], such a newline would cause the
sharder to fail, complaining about invalid header values when trying to create
the shard containers. On older versions of Python, it would most likely cause a
parsing error in the container-server that was trying to handle the PUT.
Now, quote all places that we pass around container paths. This includes:
* The X-Container-Sysmeta-Shard-(Quoted-)Root sent when creating the (empty)
remote shards
* The X-Container-Sysmeta-Shard-(Quoted-)Root included when initializing the
local handoff for cleaving
* The X-Backend-(Quoted-)Container-Path the proxy sends to the object-server
for container updates
* The Location header the container-server sends to the object-updater
Note that a new header was required in requests so that servers would
know whether the value should be unquoted or not. We can get away with
reusing Location in responses by having clients opt-in to quoting with
a new X-Backend-Accept-Quoted-Location header.
During a rolling upgrade,
* old object-servers servicing requests from new proxy-servers will
not know about the container path override and so will try to update
the root container,
* in general, object updates are more likely to land in the root
container; the sharder will deal with them as misplaced objects, and
* shard containers created by new code on servers running old code
will think they are root containers until the server is running new
code, too; during this time they'll fail the sharder audit and report
stats to their account, but both of these should get cleared up upon
upgrade.
Drive-by: fix a "conainer_name" typo that prevented us from testing that
we can shard a container with unicode in its name. Also, add more UTF8
probe tests.
[0] See https://bugs.python.org/issue22928
Change-Id: Ie08f36e31a448a547468dd85911c3a3bc30e89f1
Closes-Bug: 1856894
2019-12-18 15:14:00 -08:00
|
|
|
expected['X-Backend-Accept-Quoted-Location'] = 'true'
|
2016-11-16 18:18:44 +00:00
|
|
|
headers_out['X-Backend-Storage-Policy-Index'] = None
|
|
|
|
do_test(headers_out, expected)
|
|
|
|
|
|
|
|
# updater should not overwrite a mismatched policy header
|
|
|
|
headers_out['X-Backend-Storage-Policy-Index'] = int(policies[1])
|
|
|
|
expected['X-Backend-Storage-Policy-Index'] = str(int(policies[1]))
|
|
|
|
do_test(headers_out, expected)
|
|
|
|
|
|
|
|
# check for case insensitivity
|
|
|
|
headers_out['user-agent'] = headers_out.pop('User-Agent')
|
|
|
|
headers_out['x-backend-storage-policy-index'] = headers_out.pop(
|
|
|
|
'X-Backend-Storage-Policy-Index')
|
|
|
|
do_test(headers_out, expected)
|
Add Storage Policy support to Object Updates
The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).
Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.) Per-policy
tempdir as well.
Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.
That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.
There's also a drive by fix to update some backend http mocks for container
update tests that we're not fully exercising their their request fakes.
Because the object server container update code is resilient to to all manor
of failure from backend requests the general intent of the tests was
unaffected but this change cleans up some confusing logging in the debug
logger output.
The object-server will send X-Storage-Policy-Index headers with all
requests to container severs, including X-Delete containers and all
object PUT/DELETE requests. This header value is persisted in the
pickle file for the update and sent along with async requests from the
object-updater as well.
The container server will extract the X-Storage-Policy-Index header from
incoming requests and apply it to container broker calls as appropriate
defaulting to the legacy storage policy 0 to support seemless migration.
DocImpact
Implements: blueprint storage-policies
Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
add to object updates
Change-Id: Ic97a422238a0d7bc2a411a71a7aba3f8b42fce4d
2014-03-17 17:54:42 -07:00
|
|
|
|
2018-05-02 10:21:11 +01:00
|
|
|
def _check_update_requests(self, requests, timestamp, policy):
|
|
|
|
# do some sanity checks on update request
|
|
|
|
expected_headers = {
|
|
|
|
'X-Size': '0',
|
|
|
|
'X-Content-Type': 'text/plain',
|
|
|
|
'X-Etag': 'd41d8cd98f00b204e9800998ecf8427e',
|
|
|
|
'X-Timestamp': timestamp.internal,
|
|
|
|
'X-Backend-Storage-Policy-Index': str(int(policy)),
|
|
|
|
'User-Agent': 'object-updater %s' % os.getpid(),
|
sharding: Better-handle newlines in container names
Previously, if you were on Python 2.7.10+ [0], such a newline would cause the
sharder to fail, complaining about invalid header values when trying to create
the shard containers. On older versions of Python, it would most likely cause a
parsing error in the container-server that was trying to handle the PUT.
Now, quote all places that we pass around container paths. This includes:
* The X-Container-Sysmeta-Shard-(Quoted-)Root sent when creating the (empty)
remote shards
* The X-Container-Sysmeta-Shard-(Quoted-)Root included when initializing the
local handoff for cleaving
* The X-Backend-(Quoted-)Container-Path the proxy sends to the object-server
for container updates
* The Location header the container-server sends to the object-updater
Note that a new header was required in requests so that servers would
know whether the value should be unquoted or not. We can get away with
reusing Location in responses by having clients opt-in to quoting with
a new X-Backend-Accept-Quoted-Location header.
During a rolling upgrade,
* old object-servers servicing requests from new proxy-servers will
not know about the container path override and so will try to update
the root container,
* in general, object updates are more likely to land in the root
container; the sharder will deal with them as misplaced objects, and
* shard containers created by new code on servers running old code
will think they are root containers until the server is running new
code, too; during this time they'll fail the sharder audit and report
stats to their account, but both of these should get cleared up upon
upgrade.
Drive-by: fix a "conainer_name" typo that prevented us from testing that
we can shard a container with unicode in its name. Also, add more UTF8
probe tests.
[0] See https://bugs.python.org/issue22928
Change-Id: Ie08f36e31a448a547468dd85911c3a3bc30e89f1
Closes-Bug: 1856894
2019-12-18 15:14:00 -08:00
|
|
|
'X-Backend-Accept-Redirect': 'true',
|
|
|
|
'X-Backend-Accept-Quoted-Location': 'true'}
|
2018-05-02 10:21:11 +01:00
|
|
|
for request in requests:
|
|
|
|
self.assertEqual('PUT', request['method'])
|
|
|
|
self.assertDictEqual(expected_headers, request['headers'])
|
|
|
|
|
|
|
|
def test_obj_put_async_root_update_redirected(self):
|
|
|
|
policies = list(POLICIES)
|
|
|
|
random.shuffle(policies)
|
|
|
|
# setup updater
|
|
|
|
conf = {
|
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'false',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
}
|
|
|
|
daemon = object_updater.ObjectUpdater(conf, logger=self.logger)
|
|
|
|
async_dir = os.path.join(self.sda1, get_async_dir(policies[0]))
|
|
|
|
os.mkdir(async_dir)
|
|
|
|
dfmanager = DiskFileManager(conf, daemon.logger)
|
|
|
|
|
|
|
|
ts_obj = next(self.ts_iter)
|
|
|
|
self._write_async_update(dfmanager, ts_obj, policies[0])
|
|
|
|
|
|
|
|
# run once
|
|
|
|
ts_redirect_1 = next(self.ts_iter)
|
|
|
|
ts_redirect_2 = next(self.ts_iter)
|
|
|
|
fake_responses = [
|
|
|
|
# first round of update attempts, newest redirect should be chosen
|
|
|
|
(200, {}),
|
|
|
|
(301, {'Location': '/.shards_a/c_shard_new/o',
|
|
|
|
'X-Backend-Redirect-Timestamp': ts_redirect_2.internal}),
|
|
|
|
(301, {'Location': '/.shards_a/c_shard_old/o',
|
|
|
|
'X-Backend-Redirect-Timestamp': ts_redirect_1.internal}),
|
|
|
|
# second round of update attempts
|
|
|
|
(200, {}),
|
|
|
|
(200, {}),
|
|
|
|
(200, {}),
|
|
|
|
]
|
|
|
|
fake_status_codes, fake_headers = zip(*fake_responses)
|
|
|
|
with mocked_http_conn(
|
|
|
|
*fake_status_codes, headers=fake_headers) as conn:
|
|
|
|
with mock.patch('swift.obj.updater.dump_recon_cache'):
|
|
|
|
daemon.run_once()
|
|
|
|
|
|
|
|
self._check_update_requests(conn.requests[:3], ts_obj, policies[0])
|
|
|
|
self._check_update_requests(conn.requests[3:], ts_obj, policies[0])
|
|
|
|
self.assertEqual(['/sda1/0/a/c/o'] * 3 +
|
|
|
|
['/sda1/0/.shards_a/c_shard_new/o'] * 3,
|
|
|
|
[req['path'] for req in conn.requests])
|
|
|
|
self.assertEqual(
|
|
|
|
{'redirects': 1, 'successes': 1,
|
|
|
|
'unlinks': 1, 'async_pendings': 1},
|
|
|
|
daemon.logger.get_increment_counts())
|
|
|
|
self.assertFalse(os.listdir(async_dir)) # no async file
|
|
|
|
|
|
|
|
def test_obj_put_async_root_update_redirected_previous_success(self):
|
|
|
|
policies = list(POLICIES)
|
|
|
|
random.shuffle(policies)
|
|
|
|
# setup updater
|
|
|
|
conf = {
|
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'false',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
}
|
|
|
|
daemon = object_updater.ObjectUpdater(conf, logger=self.logger)
|
|
|
|
async_dir = os.path.join(self.sda1, get_async_dir(policies[0]))
|
|
|
|
os.mkdir(async_dir)
|
|
|
|
dfmanager = DiskFileManager(conf, daemon.logger)
|
|
|
|
|
|
|
|
ts_obj = next(self.ts_iter)
|
|
|
|
self._write_async_update(dfmanager, ts_obj, policies[0])
|
|
|
|
orig_async_path, orig_async_data = self._check_async_file(async_dir)
|
|
|
|
|
|
|
|
# run once
|
|
|
|
with mocked_http_conn(
|
|
|
|
507, 200, 507) as conn:
|
|
|
|
with mock.patch('swift.obj.updater.dump_recon_cache'):
|
|
|
|
daemon.run_once()
|
|
|
|
|
|
|
|
self._check_update_requests(conn.requests, ts_obj, policies[0])
|
|
|
|
self.assertEqual(['/sda1/0/a/c/o'] * 3,
|
|
|
|
[req['path'] for req in conn.requests])
|
|
|
|
self.assertEqual(
|
|
|
|
{'failures': 1, 'async_pendings': 1},
|
|
|
|
daemon.logger.get_increment_counts())
|
|
|
|
async_path, async_data = self._check_async_file(async_dir)
|
|
|
|
self.assertEqual(dict(orig_async_data, successes=[1]), async_data)
|
|
|
|
|
|
|
|
# run again - expect 3 redirected updates despite previous success
|
|
|
|
ts_redirect = next(self.ts_iter)
|
|
|
|
resp_headers_1 = {'Location': '/.shards_a/c_shard_1/o',
|
|
|
|
'X-Backend-Redirect-Timestamp': ts_redirect.internal}
|
|
|
|
fake_responses = (
|
|
|
|
# 1st round of redirects, 2nd round of redirects
|
|
|
|
[(301, resp_headers_1)] * 2 + [(200, {})] * 3)
|
|
|
|
fake_status_codes, fake_headers = zip(*fake_responses)
|
|
|
|
with mocked_http_conn(
|
|
|
|
*fake_status_codes, headers=fake_headers) as conn:
|
|
|
|
with mock.patch('swift.obj.updater.dump_recon_cache'):
|
|
|
|
daemon.run_once()
|
|
|
|
|
|
|
|
self._check_update_requests(conn.requests[:2], ts_obj, policies[0])
|
|
|
|
self._check_update_requests(conn.requests[2:], ts_obj, policies[0])
|
|
|
|
root_part = daemon.container_ring.get_part('a/c')
|
|
|
|
shard_1_part = daemon.container_ring.get_part('.shards_a/c_shard_1')
|
|
|
|
self.assertEqual(
|
|
|
|
['/sda1/%s/a/c/o' % root_part] * 2 +
|
|
|
|
['/sda1/%s/.shards_a/c_shard_1/o' % shard_1_part] * 3,
|
|
|
|
[req['path'] for req in conn.requests])
|
|
|
|
self.assertEqual(
|
|
|
|
{'redirects': 1, 'successes': 1, 'failures': 1, 'unlinks': 1,
|
|
|
|
'async_pendings': 1},
|
|
|
|
daemon.logger.get_increment_counts())
|
|
|
|
self.assertFalse(os.listdir(async_dir)) # no async file
|
|
|
|
|
|
|
|
def _check_async_file(self, async_dir):
|
|
|
|
async_subdirs = os.listdir(async_dir)
|
|
|
|
self.assertEqual([mock.ANY], async_subdirs)
|
|
|
|
async_files = os.listdir(os.path.join(async_dir, async_subdirs[0]))
|
|
|
|
self.assertEqual([mock.ANY], async_files)
|
|
|
|
async_path = os.path.join(
|
|
|
|
async_dir, async_subdirs[0], async_files[0])
|
2019-02-25 14:00:45 -08:00
|
|
|
with open(async_path, 'rb') as fd:
|
2018-05-02 10:21:11 +01:00
|
|
|
async_data = pickle.load(fd)
|
|
|
|
return async_path, async_data
|
|
|
|
|
|
|
|
def _check_obj_put_async_update_bad_redirect_headers(self, headers):
|
|
|
|
policies = list(POLICIES)
|
|
|
|
random.shuffle(policies)
|
|
|
|
# setup updater
|
|
|
|
conf = {
|
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'false',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
}
|
|
|
|
daemon = object_updater.ObjectUpdater(conf, logger=self.logger)
|
|
|
|
async_dir = os.path.join(self.sda1, get_async_dir(policies[0]))
|
|
|
|
os.mkdir(async_dir)
|
|
|
|
dfmanager = DiskFileManager(conf, daemon.logger)
|
|
|
|
|
|
|
|
ts_obj = next(self.ts_iter)
|
|
|
|
self._write_async_update(dfmanager, ts_obj, policies[0])
|
|
|
|
orig_async_path, orig_async_data = self._check_async_file(async_dir)
|
|
|
|
|
|
|
|
fake_responses = [
|
|
|
|
(301, headers),
|
|
|
|
(301, headers),
|
|
|
|
(301, headers),
|
|
|
|
]
|
|
|
|
fake_status_codes, fake_headers = zip(*fake_responses)
|
|
|
|
with mocked_http_conn(
|
|
|
|
*fake_status_codes, headers=fake_headers) as conn:
|
|
|
|
with mock.patch('swift.obj.updater.dump_recon_cache'):
|
|
|
|
daemon.run_once()
|
|
|
|
|
|
|
|
self._check_update_requests(conn.requests, ts_obj, policies[0])
|
|
|
|
self.assertEqual(['/sda1/0/a/c/o'] * 3,
|
|
|
|
[req['path'] for req in conn.requests])
|
|
|
|
self.assertEqual(
|
|
|
|
{'failures': 1, 'async_pendings': 1},
|
|
|
|
daemon.logger.get_increment_counts())
|
|
|
|
# async file still intact
|
|
|
|
async_path, async_data = self._check_async_file(async_dir)
|
|
|
|
self.assertEqual(orig_async_path, async_path)
|
|
|
|
self.assertEqual(orig_async_data, async_data)
|
|
|
|
return daemon
|
|
|
|
|
|
|
|
def test_obj_put_async_root_update_missing_location_header(self):
|
|
|
|
headers = {
|
|
|
|
'X-Backend-Redirect-Timestamp': next(self.ts_iter).internal}
|
|
|
|
self._check_obj_put_async_update_bad_redirect_headers(headers)
|
|
|
|
|
|
|
|
def test_obj_put_async_root_update_bad_location_header(self):
|
|
|
|
headers = {
|
|
|
|
'Location': 'bad bad bad',
|
|
|
|
'X-Backend-Redirect-Timestamp': next(self.ts_iter).internal}
|
|
|
|
daemon = self._check_obj_put_async_update_bad_redirect_headers(headers)
|
|
|
|
error_lines = daemon.logger.get_lines_for_level('error')
|
|
|
|
self.assertIn('Container update failed', error_lines[0])
|
|
|
|
self.assertIn('Invalid path: bad%20bad%20bad', error_lines[0])
|
|
|
|
|
|
|
|
def test_obj_put_async_shard_update_redirected_twice(self):
|
|
|
|
policies = list(POLICIES)
|
|
|
|
random.shuffle(policies)
|
|
|
|
# setup updater
|
|
|
|
conf = {
|
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'false',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
}
|
|
|
|
daemon = object_updater.ObjectUpdater(conf, logger=self.logger)
|
|
|
|
async_dir = os.path.join(self.sda1, get_async_dir(policies[0]))
|
|
|
|
os.mkdir(async_dir)
|
|
|
|
dfmanager = DiskFileManager(conf, daemon.logger)
|
|
|
|
|
|
|
|
ts_obj = next(self.ts_iter)
|
|
|
|
self._write_async_update(dfmanager, ts_obj, policies[0],
|
|
|
|
container_path='.shards_a/c_shard_older')
|
|
|
|
orig_async_path, orig_async_data = self._check_async_file(async_dir)
|
|
|
|
|
|
|
|
# run once
|
|
|
|
ts_redirect_1 = next(self.ts_iter)
|
|
|
|
ts_redirect_2 = next(self.ts_iter)
|
|
|
|
ts_redirect_3 = next(self.ts_iter)
|
|
|
|
fake_responses = [
|
|
|
|
# 1st round of redirects, newest redirect should be chosen
|
|
|
|
(301, {'Location': '/.shards_a/c_shard_old/o',
|
|
|
|
'X-Backend-Redirect-Timestamp': ts_redirect_1.internal}),
|
sharding: Better-handle newlines in container names
Previously, if you were on Python 2.7.10+ [0], such a newline would cause the
sharder to fail, complaining about invalid header values when trying to create
the shard containers. On older versions of Python, it would most likely cause a
parsing error in the container-server that was trying to handle the PUT.
Now, quote all places that we pass around container paths. This includes:
* The X-Container-Sysmeta-Shard-(Quoted-)Root sent when creating the (empty)
remote shards
* The X-Container-Sysmeta-Shard-(Quoted-)Root included when initializing the
local handoff for cleaving
* The X-Backend-(Quoted-)Container-Path the proxy sends to the object-server
for container updates
* The Location header the container-server sends to the object-updater
Note that a new header was required in requests so that servers would
know whether the value should be unquoted or not. We can get away with
reusing Location in responses by having clients opt-in to quoting with
a new X-Backend-Accept-Quoted-Location header.
During a rolling upgrade,
* old object-servers servicing requests from new proxy-servers will
not know about the container path override and so will try to update
the root container,
* in general, object updates are more likely to land in the root
container; the sharder will deal with them as misplaced objects, and
* shard containers created by new code on servers running old code
will think they are root containers until the server is running new
code, too; during this time they'll fail the sharder audit and report
stats to their account, but both of these should get cleared up upon
upgrade.
Drive-by: fix a "conainer_name" typo that prevented us from testing that
we can shard a container with unicode in its name. Also, add more UTF8
probe tests.
[0] See https://bugs.python.org/issue22928
Change-Id: Ie08f36e31a448a547468dd85911c3a3bc30e89f1
Closes-Bug: 1856894
2019-12-18 15:14:00 -08:00
|
|
|
(301, {'Location': '/.shards_a/c%5Fshard%5Fnew/o',
|
|
|
|
'X-Backend-Location-Is-Quoted': 'true',
|
2018-05-02 10:21:11 +01:00
|
|
|
'X-Backend-Redirect-Timestamp': ts_redirect_2.internal}),
|
sharding: Better-handle newlines in container names
Previously, if you were on Python 2.7.10+ [0], such a newline would cause the
sharder to fail, complaining about invalid header values when trying to create
the shard containers. On older versions of Python, it would most likely cause a
parsing error in the container-server that was trying to handle the PUT.
Now, quote all places that we pass around container paths. This includes:
* The X-Container-Sysmeta-Shard-(Quoted-)Root sent when creating the (empty)
remote shards
* The X-Container-Sysmeta-Shard-(Quoted-)Root included when initializing the
local handoff for cleaving
* The X-Backend-(Quoted-)Container-Path the proxy sends to the object-server
for container updates
* The Location header the container-server sends to the object-updater
Note that a new header was required in requests so that servers would
know whether the value should be unquoted or not. We can get away with
reusing Location in responses by having clients opt-in to quoting with
a new X-Backend-Accept-Quoted-Location header.
During a rolling upgrade,
* old object-servers servicing requests from new proxy-servers will
not know about the container path override and so will try to update
the root container,
* in general, object updates are more likely to land in the root
container; the sharder will deal with them as misplaced objects, and
* shard containers created by new code on servers running old code
will think they are root containers until the server is running new
code, too; during this time they'll fail the sharder audit and report
stats to their account, but both of these should get cleared up upon
upgrade.
Drive-by: fix a "conainer_name" typo that prevented us from testing that
we can shard a container with unicode in its name. Also, add more UTF8
probe tests.
[0] See https://bugs.python.org/issue22928
Change-Id: Ie08f36e31a448a547468dd85911c3a3bc30e89f1
Closes-Bug: 1856894
2019-12-18 15:14:00 -08:00
|
|
|
(301, {'Location': '/.shards_a/c%5Fshard%5Fold/o',
|
|
|
|
'X-Backend-Location-Is-Quoted': 'true',
|
2018-05-02 10:21:11 +01:00
|
|
|
'X-Backend-Redirect-Timestamp': ts_redirect_1.internal}),
|
|
|
|
# 2nd round of redirects
|
|
|
|
(301, {'Location': '/.shards_a/c_shard_newer/o',
|
|
|
|
'X-Backend-Redirect-Timestamp': ts_redirect_3.internal}),
|
|
|
|
(301, {'Location': '/.shards_a/c_shard_newer/o',
|
|
|
|
'X-Backend-Redirect-Timestamp': ts_redirect_3.internal}),
|
|
|
|
(301, {'Location': '/.shards_a/c_shard_newer/o',
|
|
|
|
'X-Backend-Redirect-Timestamp': ts_redirect_3.internal}),
|
|
|
|
]
|
|
|
|
fake_status_codes, fake_headers = zip(*fake_responses)
|
|
|
|
with mocked_http_conn(
|
|
|
|
*fake_status_codes, headers=fake_headers) as conn:
|
|
|
|
with mock.patch('swift.obj.updater.dump_recon_cache'):
|
|
|
|
daemon.run_once()
|
|
|
|
|
|
|
|
self._check_update_requests(conn.requests, ts_obj, policies[0])
|
|
|
|
# only *one* set of redirected requests is attempted per cycle
|
|
|
|
older_part = daemon.container_ring.get_part('.shards_a/c_shard_older')
|
|
|
|
new_part = daemon.container_ring.get_part('.shards_a/c_shard_new')
|
|
|
|
newer_part = daemon.container_ring.get_part('.shards_a/c_shard_newer')
|
|
|
|
self.assertEqual(
|
|
|
|
['/sda1/%s/.shards_a/c_shard_older/o' % older_part] * 3 +
|
|
|
|
['/sda1/%s/.shards_a/c_shard_new/o' % new_part] * 3,
|
|
|
|
[req['path'] for req in conn.requests])
|
|
|
|
self.assertEqual(
|
|
|
|
{'redirects': 2, 'async_pendings': 1},
|
|
|
|
daemon.logger.get_increment_counts())
|
|
|
|
# update failed, we still have pending file with most recent redirect
|
|
|
|
# response Location header value added to data
|
|
|
|
async_path, async_data = self._check_async_file(async_dir)
|
|
|
|
self.assertEqual(orig_async_path, async_path)
|
|
|
|
self.assertEqual(
|
|
|
|
dict(orig_async_data, container_path='.shards_a/c_shard_newer',
|
|
|
|
redirect_history=['.shards_a/c_shard_new',
|
|
|
|
'.shards_a/c_shard_newer']),
|
|
|
|
async_data)
|
|
|
|
|
|
|
|
# next cycle, should get latest redirect from pickled async update
|
|
|
|
fake_responses = [(200, {})] * 3
|
|
|
|
fake_status_codes, fake_headers = zip(*fake_responses)
|
|
|
|
with mocked_http_conn(
|
|
|
|
*fake_status_codes, headers=fake_headers) as conn:
|
|
|
|
with mock.patch('swift.obj.updater.dump_recon_cache'):
|
|
|
|
daemon.run_once()
|
|
|
|
|
|
|
|
self._check_update_requests(conn.requests, ts_obj, policies[0])
|
|
|
|
self.assertEqual(
|
|
|
|
['/sda1/%s/.shards_a/c_shard_newer/o' % newer_part] * 3,
|
|
|
|
[req['path'] for req in conn.requests])
|
|
|
|
self.assertEqual(
|
|
|
|
{'redirects': 2, 'successes': 1, 'unlinks': 1,
|
|
|
|
'async_pendings': 1},
|
|
|
|
daemon.logger.get_increment_counts())
|
|
|
|
self.assertFalse(os.listdir(async_dir)) # no async file
|
|
|
|
|
|
|
|
def test_obj_put_async_update_redirection_loop(self):
|
|
|
|
policies = list(POLICIES)
|
|
|
|
random.shuffle(policies)
|
|
|
|
# setup updater
|
|
|
|
conf = {
|
|
|
|
'devices': self.devices_dir,
|
|
|
|
'mount_check': 'false',
|
|
|
|
'swift_dir': self.testdir,
|
|
|
|
}
|
|
|
|
daemon = object_updater.ObjectUpdater(conf, logger=self.logger)
|
|
|
|
async_dir = os.path.join(self.sda1, get_async_dir(policies[0]))
|
|
|
|
os.mkdir(async_dir)
|
|
|
|
dfmanager = DiskFileManager(conf, daemon.logger)
|
|
|
|
|
|
|
|
ts_obj = next(self.ts_iter)
|
|
|
|
self._write_async_update(dfmanager, ts_obj, policies[0])
|
|
|
|
orig_async_path, orig_async_data = self._check_async_file(async_dir)
|
|
|
|
|
|
|
|
# run once
|
|
|
|
ts_redirect = next(self.ts_iter)
|
|
|
|
|
|
|
|
resp_headers_1 = {'Location': '/.shards_a/c_shard_1/o',
|
|
|
|
'X-Backend-Redirect-Timestamp': ts_redirect.internal}
|
|
|
|
resp_headers_2 = {'Location': '/.shards_a/c_shard_2/o',
|
|
|
|
'X-Backend-Redirect-Timestamp': ts_redirect.internal}
|
|
|
|
fake_responses = (
|
|
|
|
# 1st round of redirects, 2nd round of redirects
|
|
|
|
[(301, resp_headers_1)] * 3 + [(301, resp_headers_2)] * 3)
|
|
|
|
fake_status_codes, fake_headers = zip(*fake_responses)
|
|
|
|
with mocked_http_conn(
|
|
|
|
*fake_status_codes, headers=fake_headers) as conn:
|
|
|
|
with mock.patch('swift.obj.updater.dump_recon_cache'):
|
|
|
|
daemon.run_once()
|
|
|
|
self._check_update_requests(conn.requests[:3], ts_obj, policies[0])
|
|
|
|
self._check_update_requests(conn.requests[3:], ts_obj, policies[0])
|
|
|
|
# only *one* set of redirected requests is attempted per cycle
|
|
|
|
root_part = daemon.container_ring.get_part('a/c')
|
|
|
|
shard_1_part = daemon.container_ring.get_part('.shards_a/c_shard_1')
|
|
|
|
shard_2_part = daemon.container_ring.get_part('.shards_a/c_shard_2')
|
|
|
|
shard_3_part = daemon.container_ring.get_part('.shards_a/c_shard_3')
|
|
|
|
self.assertEqual(['/sda1/%s/a/c/o' % root_part] * 3 +
|
|
|
|
['/sda1/%s/.shards_a/c_shard_1/o' % shard_1_part] * 3,
|
|
|
|
[req['path'] for req in conn.requests])
|
|
|
|
self.assertEqual(
|
|
|
|
{'redirects': 2, 'async_pendings': 1},
|
|
|
|
daemon.logger.get_increment_counts())
|
|
|
|
# update failed, we still have pending file with most recent redirect
|
|
|
|
# response Location header value added to data
|
|
|
|
async_path, async_data = self._check_async_file(async_dir)
|
|
|
|
self.assertEqual(orig_async_path, async_path)
|
|
|
|
self.assertEqual(
|
|
|
|
dict(orig_async_data, container_path='.shards_a/c_shard_2',
|
|
|
|
redirect_history=['.shards_a/c_shard_1',
|
|
|
|
'.shards_a/c_shard_2']),
|
|
|
|
async_data)
|
|
|
|
|
|
|
|
# next cycle, more redirects! first is to previously visited location
|
|
|
|
resp_headers_3 = {'Location': '/.shards_a/c_shard_3/o',
|
|
|
|
'X-Backend-Redirect-Timestamp': ts_redirect.internal}
|
|
|
|
fake_responses = (
|
|
|
|
# 1st round of redirects, 2nd round of redirects
|
|
|
|
[(301, resp_headers_1)] * 3 + [(301, resp_headers_3)] * 3)
|
|
|
|
fake_status_codes, fake_headers = zip(*fake_responses)
|
|
|
|
with mocked_http_conn(
|
|
|
|
*fake_status_codes, headers=fake_headers) as conn:
|
|
|
|
with mock.patch('swift.obj.updater.dump_recon_cache'):
|
|
|
|
daemon.run_once()
|
|
|
|
self._check_update_requests(conn.requests[:3], ts_obj, policies[0])
|
|
|
|
self._check_update_requests(conn.requests[3:], ts_obj, policies[0])
|
|
|
|
# first try the previously persisted container path, response to that
|
|
|
|
# creates a loop so ignore and send to root
|
|
|
|
self.assertEqual(
|
|
|
|
['/sda1/%s/.shards_a/c_shard_2/o' % shard_2_part] * 3 +
|
|
|
|
['/sda1/%s/a/c/o' % root_part] * 3,
|
|
|
|
[req['path'] for req in conn.requests])
|
|
|
|
self.assertEqual(
|
|
|
|
{'redirects': 4, 'async_pendings': 1},
|
|
|
|
daemon.logger.get_increment_counts())
|
|
|
|
# update failed, we still have pending file with most recent redirect
|
|
|
|
# response Location header value from root added to persisted data
|
|
|
|
async_path, async_data = self._check_async_file(async_dir)
|
|
|
|
self.assertEqual(orig_async_path, async_path)
|
|
|
|
# note: redirect_history was reset when falling back to root
|
|
|
|
self.assertEqual(
|
|
|
|
dict(orig_async_data, container_path='.shards_a/c_shard_3',
|
|
|
|
redirect_history=['.shards_a/c_shard_3']),
|
|
|
|
async_data)
|
|
|
|
|
|
|
|
# next cycle, more redirects! first is to a location visited previously
|
|
|
|
# but not since last fall back to root, so that location IS tried;
|
|
|
|
# second is to a location visited since last fall back to root so that
|
|
|
|
# location is NOT tried
|
|
|
|
fake_responses = (
|
|
|
|
# 1st round of redirects, 2nd round of redirects
|
|
|
|
[(301, resp_headers_1)] * 3 + [(301, resp_headers_3)] * 3)
|
|
|
|
fake_status_codes, fake_headers = zip(*fake_responses)
|
|
|
|
with mocked_http_conn(
|
|
|
|
*fake_status_codes, headers=fake_headers) as conn:
|
|
|
|
with mock.patch('swift.obj.updater.dump_recon_cache'):
|
|
|
|
daemon.run_once()
|
|
|
|
self._check_update_requests(conn.requests, ts_obj, policies[0])
|
|
|
|
self.assertEqual(
|
|
|
|
['/sda1/%s/.shards_a/c_shard_3/o' % shard_3_part] * 3 +
|
|
|
|
['/sda1/%s/.shards_a/c_shard_1/o' % shard_1_part] * 3,
|
|
|
|
[req['path'] for req in conn.requests])
|
|
|
|
self.assertEqual(
|
|
|
|
{'redirects': 6, 'async_pendings': 1},
|
|
|
|
daemon.logger.get_increment_counts())
|
|
|
|
# update failed, we still have pending file, but container_path is None
|
|
|
|
# because most recent redirect location was a repeat
|
|
|
|
async_path, async_data = self._check_async_file(async_dir)
|
|
|
|
self.assertEqual(orig_async_path, async_path)
|
|
|
|
self.assertEqual(
|
|
|
|
dict(orig_async_data, container_path=None,
|
|
|
|
redirect_history=[]),
|
|
|
|
async_data)
|
|
|
|
|
|
|
|
# next cycle, persisted container path is None so update should go to
|
|
|
|
# root, this time it succeeds
|
|
|
|
fake_responses = [(200, {})] * 3
|
|
|
|
fake_status_codes, fake_headers = zip(*fake_responses)
|
|
|
|
with mocked_http_conn(
|
|
|
|
*fake_status_codes, headers=fake_headers) as conn:
|
|
|
|
with mock.patch('swift.obj.updater.dump_recon_cache'):
|
|
|
|
daemon.run_once()
|
|
|
|
self._check_update_requests(conn.requests, ts_obj, policies[0])
|
|
|
|
self.assertEqual(['/sda1/%s/a/c/o' % root_part] * 3,
|
|
|
|
[req['path'] for req in conn.requests])
|
|
|
|
self.assertEqual(
|
|
|
|
{'redirects': 6, 'successes': 1, 'unlinks': 1,
|
|
|
|
'async_pendings': 1},
|
|
|
|
daemon.logger.get_increment_counts())
|
|
|
|
self.assertFalse(os.listdir(async_dir)) # no async file
|
|
|
|
|
2010-07-12 17:03:45 -05:00
|
|
|
|
|
|
|
if __name__ == '__main__':
|
|
|
|
unittest.main()
|