For some reason, when we switched from py36 on centos8 to py39 on
centos9, these two tests started failing. Looks like a disagreement
about whether the canonical path for a bucket request should have
a trailing slash or not.
Mark them as known-failures for now so we can stay aware of any
other new breakage brought on by swift code changes.
Related-Change: I4f6b9c07af7bc768654f1a5d0c66b048e0f2c9c1
Change-Id: If990752c7ef7667182dbe18e49679e48c0e3d42d
While switching how some executable scripts were configured, I saw
some strange rolling-upgrade failures that seemed to indicate that
the new invocation method was trying to be used with old code. It
seems like it maybe has something to do with whether swift was
installed to /usr/local/lib/python3.9/site-packages/ or
/usr/local/lib64/python3.9/site-packages/ but I'm not entirely
sure.
At any rate, a proper package manager ought to uninstall the old
version then install the new one, so it seems reasonable to do that
with pip, too.
Change-Id: I12e84745e7601d162755bc9d0f1cda7b63e92197
Under a multi-region deployment with a single Keystone server,
specifying the Keystone auth credentials isn't enough. Indeed,
Castellan succeeds when logging-in, but may use the wrong
Barbican endpoint (if there are 2 Barbican deployed). This is
what happened to us, when deploying our 2nd region.
They way to fix it would be to tell Castellan what region to use,
unfortunately, there's no such option in Castellan. Though we may
specify the barbican_endpoint, which is what this patch allows.
Change-Id: Ib7f4219ef5fdef65e9cfd5701e28b5288741783e
The size in bytes from object metadata of expiring objects are stored in
expirey queue entries under the content_type field.
The x-content-type-timestamp take from object metadata is provided along
with the x-content-type update so the container replicator resolves the
latest content-type and ensures eventual consistency.
UpgradeImpact: During rolling upgrades you should expect expirer queue
entries to continue lacking swift_expirer_bytes= annotations until ALL
object servers replicas have been upgraded to new code.
Co-Authored-By: Clay Gerrard <clay.gerrard@gmail.com>
Change-Id: Ie4b25f1bd16def4069878983049b83de06f68e54
Remove swift-tox-py36-centos-8-stream job entirely.
Move the following jobs to CentOS 9:
- swift-tox-func-s3api-ceph-s3tests-tempauth
- swift-tox-func-s3api-tests-tempauth
- swift-multinode-rolling-upgrade, as well as the other rolling
upgrade jobs
Remove the swift-multinode-rolling-upgrade-victoria job, as py39
support (required for CentOS 9) was not added until wallaby.
Change-Id: I4f6b9c07af7bc768654f1a5d0c66b048e0f2c9c1
There was an abandoned change that made reference to a RecussionError
when running a probe test that imported boto3 that had something to do
with eventlet, ssl and a transitive dependency on requests-mock, but the
fix that actually got merged seemed to depend on another change to
tox.ini that disables request-mock when we run pytest.
Either way, we already import from boto3 at the top of probe tests and
it's in test-requirements; so we require it to be installed even if you
don't have s3api in your pipeline.
Related-Change: I789b257635c031ac0cb6e4b5980f741e0cb5244d
Related-Change: I2793e335a08ad373c49cbbe6759d4e97cc420867
Related-Change: If14e4d2c1af2efcbc99e9b6fe10973a7eb94d589
Change-Id: Id2662bfc5ef2f21f901f1c98e6389c4cb01818a2
We've been working toward separating our logger from our statsd client.
This is generally a good idea; it's always been a little weird to have
our special-case loggers that would allow you to *also* increment some
counters.
The end goal is to take a bunch of places that look like
logger = utils.get_logger(conf)
...
logger.info(...)
logger.increment(...)
and turn them into something more like
logger = logs.get_adapted_logger(conf)
stats = statsd_client.get_statsd_client(conf, logger=logger)
...
logger.info(...)
stats.increment(...)
Take a lesson from logging: callers don't need to know whether the
log_level is high enough that their message will be logged, or even
whether logging is enabled at all. Code wanting to emit stats shouldn't
need to know whether statsd collection has been configured, either.
Co-Authored-By: Alistair Coles <alistairncoles@gmail.com>
Change-Id: I6eb5b27a387cc2b7310ee11cc49d38fd2b6cbab8
Even if stdlib socket is probably patched by the time StatsdClient
creates a socket, we want to import the green socket module explicitly
for better testing.
Move test_statsd.py to test_statsd_client.py so it matches the naming
convention of the rest of our test files.
Fix some patching of utils in test_statsd_client to patch
statsd_client.
Rename some vars in test_statsd_client that shadowed the statsd_client
module name.
Move some utils tests out of test_statsd_client and back into
test_utils.
Related-Change: I4b5b12a3b0288b696a39903264741bc862a94ad7
Change-Id: I3de22b7f15dd386fa9c873587782f0dfc4c42a27
Adds ClosingMapper class which is like map() but closes the
iterable.
Co-Authored-By: Alistair Coles <alistairncoles@gmail.com>
Change-Id: Idd0ac21b365a138b065f01d05a257af62ea88177
The boto library was last updated two years ago and has
rusted to the point that it's unusable on py312 -- see
https://github.com/boto/boto/issues/3951
We should transition all of these tests to boto3 equivalents,
but this should help out in the meantime.
Related-Bug: #1557260
Related-Bug: #2063367
Change-Id: If95f45371f352c6a2d16be1a3e1b64e265bccfb4
This shouldn't impact real servers, as those processes were about to
wrap up anyway. It *can* cause some confusing behaviors in tests,
though.
Change-Id: Ifd8a64efcd3fc983596ba7cd9fe28eb9663c93d6
- Move statsd client into it's own module
- Move all logging functions into their own module
- Move all config functions into their own module
- Move all helper functions into their own module
Partial-Bug: #2015274
Change-Id: Ic4b5005e3efffa8dba17d91a41e46d5c68533f9a
