These should be fine on jammy/py310 now.
Change-Id: Iae3daadc9d880b4980aa2305df626929c93b475d
Closes-Bug: #1996627
Related-Bug: #1999278
Related-Change: Iae28097668213aa0734837ff21aef83251167d19
No sooner do we fix the gate than tox has a new release that breaks
it again. Let's give them a bit to settle down; in the mean time, stick
with 3.x.
See https://github.com/tox-dev/tox/issues/2811
Also simplify our warning suppressions. The message filter is a regex,
so any prefix of the message will suffice. This allows us to also drop a
new message seen on CentOS 8:
CryptographyDeprecationWarning: Python 3.6 is no longer
supported by the Python core team. Therefore, support for
it is deprecated in cryptography. The next release of
cryptography (40.0) will be the last to support Python 3.6.
As we've previously seen with cryptography warnings, this can slow down
our probe tests to the point that they time out.
Change-Id: I316170442c67c1b4a5b87f9a1168cc04ca2417b8
For tox 3.x and earlier, passenv was a space-separated list; as of tox
4.0.0, it's comma-separated. For a while, our spaces would be silently
included in the now-one-and-only passenv value parsed (which wasn't
great, but mostly just caused confusion) -- as of tox 4.0.6, however, it
became a hard error, and all tests would fail like
pass_env values cannot contain whitespace, use comma to have multiple
values in a single line, invalid values found 'SWIFT_* *_proxy'
Unfortunately, we don't really know what versions of tox all our various
stakeholders might want/need to use (though we previously set a
minversion of 2.3.2). We might be able to spread values over multiple
lines to make it compatible with both tox 3 *and* tox 4, but I'm fairly
certain *_proxy was only included for some variables that are recent
versions of tox include by default anyway, so just increase our
minversion (which was too low, anyway -- allowlist_externals which we
already configure was added in 3.18.0) and get rid of *_proxy.
FWIW, python-swiftclient was already specifying 3.18.0 as a minversion,
so I expect the new minversion to not be a problem.
Also, add ./.functests to a bunch of allowlist_externals, as newer tox
is more strict about that sort of thing.
Drop skipsdist in a bunch of places so we can import swift from func
tests and docs. (Still not sure why I don't see us hitting a similar
problem for unit tests...)
Change-Id: I4be1e86e3291ad1619c695fb93d7cadf053b556d
nose has not seen active development for many years now. With py310, we
can no longer use it due to import errors.
Also update lower contraints
Closes-Bug: #1993531
Change-Id: I215ba0d4654c9c637c3b97953d8659ac80892db8
As per the community wide goal to migrate the CI/CD from
Ubuntu Focal to Ubuntu jammy, we need to merge the devstack, tox base
jobs to jammy on Nov 18. But swift-dsvm-functional job is
failing on Ubuntu Jammy.
To move ahead to merge the base job patches we need to pin the
swift-dsvm-functional job nodeset to Focal until this is fixed
for Jammy.
Needed-By: https://review.opendev.org/c/openstack/devstack/+/860795
Related-bug: #1996627
Change-Id: Ia35e55782592175a6a9aaafd59d72a0ff8362d61
Upstream CPython broke our HTTP parsing; while we can fix our own
HttpProtocol, previous tags won't have the fix (naturally).
See also: 4abab6b603
Change-Id: Ibe67b1a485350967e37809ba8575a33eba56ee97
Related-Change: https://review.opendev.org/c/openstack/swift/+/863441
We'll want that by the time we can add a py310 job. It'll also make us
be explicit about the OS to use for py27 and py36-py39 jobs.
Also, update bindep so we don't try to install py2 stuff on jammy.
Change-Id: If70cd2fc03d10e55cd782ec8ffc87bd2b2b321ea
At some point, this became a required parameter.
Change-Id: I4d807f3b3649a45dbb2166bb8e911c45fb9cb701
Related-Change: Iebf474c9351e4246d7ab2072b48a50e93dbf0b94
Most of the time, we're so resource constrained that we trip the
three-hour (!!) job timeout, while the x86_64 job can typically complete
within an hour. When the arm64 probe tests *do* fail, they've often
failed due to eventual-consistency problems; things like object-updaters
popping 10s timeouts and not getting asyncs off disk.
The job last passed back in January.
Change-Id: I31efa3fef673a5541505e4855e52bfd0c9668ffd
As part of that, the ceph test runner needed up-rev'ing to run under
py3. As a result, the known-failures shifted.
Trim the on-demand rolling upgrade jobs list -- now that it's running
py3, we only expect it to pass for train and beyond.
Also, pin smmap version on py2 -- otherwise, the remaining experimental
jobs running on centos-7 fail.
Change-Id: Ibe46aecf0f4461be59eb206bfe9063cc1bfff706
This was added while debugging issues with the FIPS jobs, and
we already have a swift-tox-func-encryption-py36-centos-8-stream
job in the experimental pipeline.
Change-Id: I77178aa7def0e02e7b7add662135d62ed7f8c697
Added jobs to run the swift functional tests when FIPS is enabled.
We'll set these jobs to be non-voting initially, so that we can
ensure that they are stable.
Change-Id: If0b4cfc1ac9a8c66085eb4dc95366d43806d5ae2
The confirmation that tests pass will still be nice come release time,
but the py36 and py39 jobs probably suffice to say the intermediary
versions work.
Change-Id: I3de9fb217b402df214430a6cbf920d7bd7694b32
Make the non-voting pipeline indicate failure when any of the jobs
fail.
Previously zuul would report "Build succeeded (ARM64 pipeline)."
even when individual job(s) had failed. Now zuul will report
"Build failed (ARM64 pipeline)." but the pipeline still does
vote on the patchset.
Change-Id: I84f59256df3aa41338df9829a565ae830ee8e847
Keystone can only provide v3 now, remove variables that no longer have
any effect within devstack.
Signed-off-by: Dr. Jens Harbott <harbott@osism.tech>
Change-Id: I66f6fd712cd14f60be39e2ee7ddd0a089cedabab
Adds:
- a centos-8 probe test on py36
- an ubuntu-bionic functest on py38
- an ubuntu-bionic functest with encryption on py38
Change-Id: Id835b49312ec04d7ce9094718b98d8e23ddba0b7
This adds support for presigned GET URLs, at least.
Note that there is no support yet for preflight requests, so a whole
bunch of other CORS stuff *doesn't* work (yet). This was just an easy
first step.
Change-Id: I43150a630a2a7620099e6bfecaed3bbe958ba423
If you've got selenium installed (and working), the whole thing can be
automated pretty well; run main.py, wait while some windows pop up (or
use xvfb-run to run things on a virtual display), then check out what
tests were run on which browsers and whether any of them failed. Exit
code is the number of failed tests.
Includes tests against:
- Account
- Containers, with various ACLs/CORS settings
- Objects
- /info
- SLOs
- DLOs
- Symlinks
Include a gate job that runs the tests in firefox.
Areas for future work:
- Install chromium and chromedriver in the gate; tests should
automatically pick up on the fact that it's available
- Capture the web browser's console logs, too, so we can get
more info when things go wrong
Change-Id: Ic1d3a062419f1133c6e2f00a598867d567358c9f
The services themselves were already runing under py3. I think we've
done about all of the py2-client-can-talk-to-py3-services testing we
need to.
Change-Id: I459d6065a3e4290768c499e7973917f7cf4ce2e7
...and, since the previous tag didn't have the Bandit pin, make the
rolling upgrade job non-voting. We should plan on backporting this so we
can check that upgrades from stable branches are still OK.
See also: https://github.com/PyCQA/bandit/issues/654
Change-Id: If7f3ad8b275271d748426133232ed06c2a1cd1de
This used to be the name of the py2 job, but now even that's gone;
I'm not sure how Zuul let us get away with this.
Change-Id: I1a2f22d592fc7245e40c645000026e4ba1fca528
Related-Change: Ia9ae0fc226dfc9b40157faebac100c10a9180c62