2014-03-31 22:56:17 -04:00
|
|
|
# Copyright (c) 2014 OpenStack Foundation
|
|
|
|
#
|
|
|
|
# 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-28 20:35:25 +05:30
|
|
|
from __future__ import print_function
|
2014-08-11 17:09:48 +01:00
|
|
|
import mock
|
2014-03-31 23:22:49 -04:00
|
|
|
import os
|
2019-08-06 10:00:41 -07:00
|
|
|
import six
|
2018-08-01 23:52:04 +00:00
|
|
|
from six.moves.urllib.parse import urlparse, urlsplit, urlunsplit
|
2014-03-31 23:22:49 -04:00
|
|
|
import sys
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
import pickle
|
2014-03-31 23:22:49 -04:00
|
|
|
import socket
|
2014-03-31 22:56:17 -04:00
|
|
|
import locale
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
import eventlet
|
|
|
|
import eventlet.debug
|
2014-03-31 23:22:49 -04:00
|
|
|
import functools
|
2014-04-09 19:15:04 +08:00
|
|
|
import random
|
2019-08-06 10:00:41 -07:00
|
|
|
import base64
|
2015-05-25 18:26:38 +02:00
|
|
|
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
from time import time, sleep
|
|
|
|
from contextlib import closing
|
|
|
|
from gzip import GzipFile
|
|
|
|
from shutil import rmtree
|
|
|
|
from tempfile import mkdtemp
|
2023-02-16 23:57:08 -08:00
|
|
|
from unittest import SkipTest
|
2015-05-25 18:26:38 +02:00
|
|
|
|
|
|
|
from six.moves.configparser import ConfigParser, NoSectionError
|
|
|
|
from six.moves import http_client
|
|
|
|
from six.moves.http_client import HTTPException
|
|
|
|
|
2014-08-11 17:09:48 +01:00
|
|
|
from swift.common.middleware.memcache import MemcacheMiddleware
|
2015-02-25 17:33:44 +00:00
|
|
|
from swift.common.storage_policy import parse_storage_policies, PolicyError
|
2016-07-20 09:51:24 +00:00
|
|
|
from swift.common.utils import set_swift_dir
|
2014-03-31 23:22:49 -04:00
|
|
|
|
2017-05-11 01:39:14 -06:00
|
|
|
from test import get_config, listen_zero
|
Add checksum to object extended attributes
Currently, our integrity checking for objects is pretty weak when it
comes to object metadata. If the extended attributes on a .data or
.meta file get corrupted in such a way that we can still unpickle it,
we don't have anything that detects that.
This could be especially bad with encrypted etags; if the encrypted
etag (X-Object-Sysmeta-Crypto-Etag or whatever it is) gets some bits
flipped, then we'll cheerfully decrypt the cipherjunk into plainjunk,
then send it to the client. Net effect is that the client sees a GET
response with an ETag that doesn't match the MD5 of the object *and*
Swift has no way of detecting and quarantining this object.
Note that, with an unencrypted object, if the ETag metadatum gets
mangled, then the object will be quarantined by the object server or
auditor, whichever notices first.
As part of this commit, I also ripped out some mocking of
getxattr/setxattr in tests. It appears to be there to allow unit tests
to run on systems where /tmp doesn't support xattrs. However, since
the mock is keyed off of inode number and inode numbers get re-used,
there's lots of leakage between different test runs. On a real FS,
unlinking a file and then creating a new one of the same name will
also reset the xattrs; this isn't the case with the mock.
The mock was pretty old; Ubuntu 12.04 and up all support xattrs in
/tmp, and recent Red Hat / CentOS releases do too. The xattr mock was
added in 2011; maybe it was to support Ubuntu Lucid Lynx?
Bonus: now you can pause a test with the debugger, inspect its files
in /tmp, and actually see the xattrs along with the data.
Since this patch now uses a real filesystem for testing filesystem
operations, tests are skipped if the underlying filesystem does not
support setting xattrs (eg tmpfs or more than 4k of xattrs on ext4).
References to "/tmp" have been replaced with calls to
tempfile.gettempdir(). This will allow setting the TMPDIR envvar in
test setup and getting an XFS filesystem instead of ext4 or tmpfs.
THIS PATCH SIGNIFICANTLY CHANGES TESTING ENVIRONMENTS
With this patch, every test environment will require TMPDIR to be
using a filesystem that supports at least 4k of extended attributes.
Neither ext4 nor tempfs support this. XFS is recommended.
So why all the SkipTests? Why not simply raise an error? We still need
the tests to run on the base image for OpenStack's CI system. Since
we were previously mocking out xattr, there wasn't a problem, but we
also weren't actually testing anything. This patch adds functionality
to validate xattr data, so we need to drop the mock.
`test.unit.skip_if_no_xattrs()` is also imported into `test.functional`
so that functional tests can import it from the functional test
namespace.
The related OpenStack CI infrastructure changes are made in
https://review.openstack.org/#/c/394600/.
Co-Authored-By: John Dickinson <me@not.mn>
Change-Id: I98a37c0d451f4960b7a12f648e4405c6c6716808
2016-06-30 16:52:58 -07:00
|
|
|
|
2021-01-22 14:21:23 -06:00
|
|
|
from test.debug_logger import debug_logger
|
|
|
|
from test.unit import FakeMemcache
|
Add checksum to object extended attributes
Currently, our integrity checking for objects is pretty weak when it
comes to object metadata. If the extended attributes on a .data or
.meta file get corrupted in such a way that we can still unpickle it,
we don't have anything that detects that.
This could be especially bad with encrypted etags; if the encrypted
etag (X-Object-Sysmeta-Crypto-Etag or whatever it is) gets some bits
flipped, then we'll cheerfully decrypt the cipherjunk into plainjunk,
then send it to the client. Net effect is that the client sees a GET
response with an ETag that doesn't match the MD5 of the object *and*
Swift has no way of detecting and quarantining this object.
Note that, with an unencrypted object, if the ETag metadatum gets
mangled, then the object will be quarantined by the object server or
auditor, whichever notices first.
As part of this commit, I also ripped out some mocking of
getxattr/setxattr in tests. It appears to be there to allow unit tests
to run on systems where /tmp doesn't support xattrs. However, since
the mock is keyed off of inode number and inode numbers get re-used,
there's lots of leakage between different test runs. On a real FS,
unlinking a file and then creating a new one of the same name will
also reset the xattrs; this isn't the case with the mock.
The mock was pretty old; Ubuntu 12.04 and up all support xattrs in
/tmp, and recent Red Hat / CentOS releases do too. The xattr mock was
added in 2011; maybe it was to support Ubuntu Lucid Lynx?
Bonus: now you can pause a test with the debugger, inspect its files
in /tmp, and actually see the xattrs along with the data.
Since this patch now uses a real filesystem for testing filesystem
operations, tests are skipped if the underlying filesystem does not
support setting xattrs (eg tmpfs or more than 4k of xattrs on ext4).
References to "/tmp" have been replaced with calls to
tempfile.gettempdir(). This will allow setting the TMPDIR envvar in
test setup and getting an XFS filesystem instead of ext4 or tmpfs.
THIS PATCH SIGNIFICANTLY CHANGES TESTING ENVIRONMENTS
With this patch, every test environment will require TMPDIR to be
using a filesystem that supports at least 4k of extended attributes.
Neither ext4 nor tempfs support this. XFS is recommended.
So why all the SkipTests? Why not simply raise an error? We still need
the tests to run on the base image for OpenStack's CI system. Since
we were previously mocking out xattr, there wasn't a problem, but we
also weren't actually testing anything. This patch adds functionality
to validate xattr data, so we need to drop the mock.
`test.unit.skip_if_no_xattrs()` is also imported into `test.functional`
so that functional tests can import it from the functional test
namespace.
The related OpenStack CI infrastructure changes are made in
https://review.openstack.org/#/c/394600/.
Co-Authored-By: John Dickinson <me@not.mn>
Change-Id: I98a37c0d451f4960b7a12f648e4405c6c6716808
2016-06-30 16:52:58 -07:00
|
|
|
# importing skip_if_no_xattrs so that functional tests can grab it from the
|
2023-02-16 23:57:08 -08:00
|
|
|
# test.functional namespace.
|
Add checksum to object extended attributes
Currently, our integrity checking for objects is pretty weak when it
comes to object metadata. If the extended attributes on a .data or
.meta file get corrupted in such a way that we can still unpickle it,
we don't have anything that detects that.
This could be especially bad with encrypted etags; if the encrypted
etag (X-Object-Sysmeta-Crypto-Etag or whatever it is) gets some bits
flipped, then we'll cheerfully decrypt the cipherjunk into plainjunk,
then send it to the client. Net effect is that the client sees a GET
response with an ETag that doesn't match the MD5 of the object *and*
Swift has no way of detecting and quarantining this object.
Note that, with an unencrypted object, if the ETag metadatum gets
mangled, then the object will be quarantined by the object server or
auditor, whichever notices first.
As part of this commit, I also ripped out some mocking of
getxattr/setxattr in tests. It appears to be there to allow unit tests
to run on systems where /tmp doesn't support xattrs. However, since
the mock is keyed off of inode number and inode numbers get re-used,
there's lots of leakage between different test runs. On a real FS,
unlinking a file and then creating a new one of the same name will
also reset the xattrs; this isn't the case with the mock.
The mock was pretty old; Ubuntu 12.04 and up all support xattrs in
/tmp, and recent Red Hat / CentOS releases do too. The xattr mock was
added in 2011; maybe it was to support Ubuntu Lucid Lynx?
Bonus: now you can pause a test with the debugger, inspect its files
in /tmp, and actually see the xattrs along with the data.
Since this patch now uses a real filesystem for testing filesystem
operations, tests are skipped if the underlying filesystem does not
support setting xattrs (eg tmpfs or more than 4k of xattrs on ext4).
References to "/tmp" have been replaced with calls to
tempfile.gettempdir(). This will allow setting the TMPDIR envvar in
test setup and getting an XFS filesystem instead of ext4 or tmpfs.
THIS PATCH SIGNIFICANTLY CHANGES TESTING ENVIRONMENTS
With this patch, every test environment will require TMPDIR to be
using a filesystem that supports at least 4k of extended attributes.
Neither ext4 nor tempfs support this. XFS is recommended.
So why all the SkipTests? Why not simply raise an error? We still need
the tests to run on the base image for OpenStack's CI system. Since
we were previously mocking out xattr, there wasn't a problem, but we
also weren't actually testing anything. This patch adds functionality
to validate xattr data, so we need to drop the mock.
`test.unit.skip_if_no_xattrs()` is also imported into `test.functional`
so that functional tests can import it from the functional test
namespace.
The related OpenStack CI infrastructure changes are made in
https://review.openstack.org/#/c/394600/.
Co-Authored-By: John Dickinson <me@not.mn>
Change-Id: I98a37c0d451f4960b7a12f648e4405c6c6716808
2016-06-30 16:52:58 -07:00
|
|
|
from test.unit import skip_if_no_xattrs as real_skip_if_no_xattrs
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
|
2014-04-09 19:15:04 +08:00
|
|
|
from swift.common import constraints, utils, ring, storage_policy
|
2014-08-11 17:09:48 +01:00
|
|
|
from swift.common.ring import Ring
|
2022-12-06 11:15:53 -08:00
|
|
|
from swift.common.http_protocol import SwiftHttpProtocol
|
|
|
|
from swift.common.wsgi import loadapp
|
2015-03-25 13:19:36 +00:00
|
|
|
from swift.common.utils import config_true_value, split_path
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
from swift.account import server as account_server
|
|
|
|
from swift.container import server as container_server
|
2014-05-06 10:54:05 -04:00
|
|
|
from swift.obj import server as object_server, mem_server as mem_object_server
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
import swift.proxy.controllers.obj
|
|
|
|
|
2015-05-25 18:26:38 +02:00
|
|
|
http_client._MAXHEADERS = constraints.MAX_HEADER_COUNT
|
2015-02-25 17:33:44 +00:00
|
|
|
DEBUG = True
|
|
|
|
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
# In order to get the proper blocking behavior of sockets without using
|
|
|
|
# threads, where we can set an arbitrary timeout for some piece of code under
|
|
|
|
# test, we use eventlet with the standard socket library patched. We have to
|
|
|
|
# perform this setup at module import time, since all the socket module
|
|
|
|
# bindings in the swiftclient code will have been made by the time nose
|
|
|
|
# invokes the package or class setup methods.
|
|
|
|
eventlet.hubs.use_hub(utils.get_hub())
|
|
|
|
eventlet.patcher.monkey_patch(all=False, socket=True)
|
|
|
|
eventlet.debug.hub_exceptions(False)
|
|
|
|
|
py3: Finish porting func tests
We were (indirectly) importing swiftclient (and therefore requests and
urllib3) before doing our eventlet monkey-patching. This would lead
boto3 (which digs an SSLContext out of urllib3) to trip RecursionErrors
on py3 similar to
>>> from ssl import SSLContext, PROTOCOL_SSLv23
>>> import eventlet
>>> eventlet.monkey_patch(socket=True)
>>> SSLContext(PROTOCOL_SSLv23).options |= 0
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.6/ssl.py", line 465, in options
super(SSLContext, SSLContext).options.__set__(self, value)
File "/usr/lib/python3.6/ssl.py", line 465, in options
super(SSLContext, SSLContext).options.__set__(self, value)
File "/usr/lib/python3.6/ssl.py", line 465, in options
super(SSLContext, SSLContext).options.__set__(self, value)
[Previous line repeated 330 more times]
RecursionError: maximum recursion depth exceeded while calling a Python object
Change-Id: I4bb59edd87336597791416c4f2a096efe0e72fe3
2019-08-07 16:16:57 -07:00
|
|
|
# swift_test_client import from swiftclient, so move after the monkey-patching
|
|
|
|
from test.functional.swift_test_client import Account, Connection, Container, \
|
|
|
|
ResponseError
|
|
|
|
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
from swiftclient import get_auth, http_connection
|
2014-03-31 23:22:49 -04:00
|
|
|
|
2014-03-31 23:51:43 -04:00
|
|
|
config = {}
|
|
|
|
web_front_end = None
|
|
|
|
normalized_urls = None
|
2014-03-31 23:22:49 -04:00
|
|
|
|
|
|
|
# If no config was read, we will fall back to old school env vars
|
2014-03-31 23:51:43 -04:00
|
|
|
swift_test_auth_version = None
|
2014-03-31 23:22:49 -04:00
|
|
|
swift_test_auth = os.environ.get('SWIFT_TEST_AUTH')
|
2015-07-16 09:35:37 +09:00
|
|
|
swift_test_user = [os.environ.get('SWIFT_TEST_USER'), None, None, '', '', '']
|
|
|
|
swift_test_key = [os.environ.get('SWIFT_TEST_KEY'), None, None, '', '', '']
|
|
|
|
swift_test_tenant = ['', '', '', '', '', '']
|
|
|
|
swift_test_perm = ['', '', '', '', '', '']
|
|
|
|
swift_test_domain = ['', '', '', '', '', '']
|
|
|
|
swift_test_user_id = ['', '', '', '', '', '']
|
|
|
|
swift_test_tenant_id = ['', '', '', '', '', '']
|
2014-03-31 23:22:49 -04:00
|
|
|
|
2017-11-07 12:05:27 +11:00
|
|
|
skip, skip2, skip3, skip_if_not_v3, skip_service_tokens, \
|
|
|
|
skip_if_no_reseller_admin = False, False, False, False, False, False
|
2014-03-31 22:56:17 -04:00
|
|
|
|
|
|
|
orig_collate = ''
|
2014-04-30 12:17:25 -06:00
|
|
|
insecure = False
|
|
|
|
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
in_process = False
|
2015-08-07 18:14:13 -05:00
|
|
|
_testdir = _test_servers = _test_coros = _test_socks = None
|
2015-03-25 13:19:36 +00:00
|
|
|
policy_specified = None
|
Add checksum to object extended attributes
Currently, our integrity checking for objects is pretty weak when it
comes to object metadata. If the extended attributes on a .data or
.meta file get corrupted in such a way that we can still unpickle it,
we don't have anything that detects that.
This could be especially bad with encrypted etags; if the encrypted
etag (X-Object-Sysmeta-Crypto-Etag or whatever it is) gets some bits
flipped, then we'll cheerfully decrypt the cipherjunk into plainjunk,
then send it to the client. Net effect is that the client sees a GET
response with an ETag that doesn't match the MD5 of the object *and*
Swift has no way of detecting and quarantining this object.
Note that, with an unencrypted object, if the ETag metadatum gets
mangled, then the object will be quarantined by the object server or
auditor, whichever notices first.
As part of this commit, I also ripped out some mocking of
getxattr/setxattr in tests. It appears to be there to allow unit tests
to run on systems where /tmp doesn't support xattrs. However, since
the mock is keyed off of inode number and inode numbers get re-used,
there's lots of leakage between different test runs. On a real FS,
unlinking a file and then creating a new one of the same name will
also reset the xattrs; this isn't the case with the mock.
The mock was pretty old; Ubuntu 12.04 and up all support xattrs in
/tmp, and recent Red Hat / CentOS releases do too. The xattr mock was
added in 2011; maybe it was to support Ubuntu Lucid Lynx?
Bonus: now you can pause a test with the debugger, inspect its files
in /tmp, and actually see the xattrs along with the data.
Since this patch now uses a real filesystem for testing filesystem
operations, tests are skipped if the underlying filesystem does not
support setting xattrs (eg tmpfs or more than 4k of xattrs on ext4).
References to "/tmp" have been replaced with calls to
tempfile.gettempdir(). This will allow setting the TMPDIR envvar in
test setup and getting an XFS filesystem instead of ext4 or tmpfs.
THIS PATCH SIGNIFICANTLY CHANGES TESTING ENVIRONMENTS
With this patch, every test environment will require TMPDIR to be
using a filesystem that supports at least 4k of extended attributes.
Neither ext4 nor tempfs support this. XFS is recommended.
So why all the SkipTests? Why not simply raise an error? We still need
the tests to run on the base image for OpenStack's CI system. Since
we were previously mocking out xattr, there wasn't a problem, but we
also weren't actually testing anything. This patch adds functionality
to validate xattr data, so we need to drop the mock.
`test.unit.skip_if_no_xattrs()` is also imported into `test.functional`
so that functional tests can import it from the functional test
namespace.
The related OpenStack CI infrastructure changes are made in
https://review.openstack.org/#/c/394600/.
Co-Authored-By: John Dickinson <me@not.mn>
Change-Id: I98a37c0d451f4960b7a12f648e4405c6c6716808
2016-06-30 16:52:58 -07:00
|
|
|
skip_if_no_xattrs = None
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
|
|
|
|
|
2014-08-11 17:09:48 +01:00
|
|
|
class FakeMemcacheMiddleware(MemcacheMiddleware):
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
"""
|
2014-08-11 17:09:48 +01:00
|
|
|
Caching middleware that fakes out caching in swift if memcached
|
|
|
|
does not appear to be running.
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
"""
|
|
|
|
|
|
|
|
def __init__(self, app, conf):
|
2014-08-11 17:09:48 +01:00
|
|
|
super(FakeMemcacheMiddleware, self).__init__(app, conf)
|
2014-11-17 12:30:15 -08:00
|
|
|
self.memcache = FakeMemcache()
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
|
|
|
|
|
2015-02-25 17:33:44 +00:00
|
|
|
class InProcessException(BaseException):
|
|
|
|
pass
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
|
|
|
|
|
2015-02-25 17:33:44 +00:00
|
|
|
def _info(msg):
|
2015-07-28 20:35:25 +05:30
|
|
|
print(msg, file=sys.stderr)
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
|
2014-08-11 17:09:48 +01:00
|
|
|
|
2015-02-25 17:33:44 +00:00
|
|
|
def _debug(msg):
|
|
|
|
if DEBUG:
|
|
|
|
_info('DEBUG: ' + msg)
|
|
|
|
|
|
|
|
|
|
|
|
def _in_process_setup_swift_conf(swift_conf_src, testdir):
|
|
|
|
# override swift.conf contents for in-process functional test runs
|
|
|
|
conf = ConfigParser()
|
|
|
|
conf.read(swift_conf_src)
|
|
|
|
try:
|
|
|
|
section = 'swift-hash'
|
|
|
|
conf.set(section, 'swift_hash_path_suffix', 'inprocfunctests')
|
|
|
|
conf.set(section, 'swift_hash_path_prefix', 'inprocfunctests')
|
|
|
|
section = 'swift-constraints'
|
|
|
|
max_file_size = (8 * 1024 * 1024) + 2 # 8 MB + 2
|
2019-03-01 12:13:27 -08:00
|
|
|
conf.set(section, 'max_file_size', str(max_file_size))
|
2015-02-25 17:33:44 +00:00
|
|
|
except NoSectionError:
|
|
|
|
msg = 'Conf file %s is missing section %s' % (swift_conf_src, section)
|
|
|
|
raise InProcessException(msg)
|
|
|
|
|
|
|
|
test_conf_file = os.path.join(testdir, 'swift.conf')
|
|
|
|
with open(test_conf_file, 'w') as fp:
|
|
|
|
conf.write(fp)
|
|
|
|
|
|
|
|
return test_conf_file
|
|
|
|
|
|
|
|
|
|
|
|
def _in_process_find_conf_file(conf_src_dir, conf_file_name, use_sample=True):
|
|
|
|
"""
|
|
|
|
Look for a file first in conf_src_dir, if it exists, otherwise optionally
|
|
|
|
look in the source tree sample 'etc' dir.
|
|
|
|
|
|
|
|
:param conf_src_dir: Directory in which to search first for conf file. May
|
|
|
|
be None
|
|
|
|
:param conf_file_name: Name of conf file
|
|
|
|
:param use_sample: If True and the conf_file_name is not found, then return
|
|
|
|
any sample conf file found in the source tree sample
|
|
|
|
'etc' dir by appending '-sample' to conf_file_name
|
|
|
|
:returns: Path to conf file
|
|
|
|
:raises InProcessException: If no conf file is found
|
|
|
|
"""
|
|
|
|
dflt_src_dir = os.path.normpath(os.path.join(os.path.abspath(__file__),
|
|
|
|
os.pardir, os.pardir, os.pardir,
|
|
|
|
'etc'))
|
|
|
|
conf_src_dir = dflt_src_dir if conf_src_dir is None else conf_src_dir
|
|
|
|
conf_file_path = os.path.join(conf_src_dir, conf_file_name)
|
|
|
|
if os.path.exists(conf_file_path):
|
|
|
|
return conf_file_path
|
|
|
|
|
|
|
|
if use_sample:
|
|
|
|
# fall back to using the corresponding sample conf file
|
|
|
|
conf_file_name += '-sample'
|
|
|
|
conf_file_path = os.path.join(dflt_src_dir, conf_file_name)
|
|
|
|
if os.path.exists(conf_file_path):
|
|
|
|
return conf_file_path
|
|
|
|
|
|
|
|
msg = 'Failed to find config file %s' % conf_file_name
|
|
|
|
raise InProcessException(msg)
|
|
|
|
|
|
|
|
|
|
|
|
def _in_process_setup_ring(swift_conf, conf_src_dir, testdir):
|
|
|
|
"""
|
|
|
|
If SWIFT_TEST_POLICY is set:
|
|
|
|
- look in swift.conf file for specified policy
|
|
|
|
- move this to be policy-0 but preserving its options
|
|
|
|
- copy its ring file to test dir, changing its devices to suit
|
|
|
|
in process testing, and renaming it to suit policy-0
|
|
|
|
Otherwise, create a default ring file.
|
|
|
|
"""
|
|
|
|
conf = ConfigParser()
|
|
|
|
conf.read(swift_conf)
|
|
|
|
sp_prefix = 'storage-policy:'
|
|
|
|
|
|
|
|
try:
|
|
|
|
# policy index 0 will be created if no policy exists in conf
|
|
|
|
policies = parse_storage_policies(conf)
|
|
|
|
except PolicyError as e:
|
|
|
|
raise InProcessException(e)
|
|
|
|
|
|
|
|
# clear all policies from test swift.conf before adding test policy back
|
|
|
|
for policy in policies:
|
|
|
|
conf.remove_section(sp_prefix + str(policy.idx))
|
|
|
|
|
|
|
|
if policy_specified:
|
|
|
|
policy_to_test = policies.get_by_name(policy_specified)
|
|
|
|
if policy_to_test is None:
|
|
|
|
raise InProcessException('Failed to find policy name "%s"'
|
|
|
|
% policy_specified)
|
|
|
|
_info('Using specified policy %s' % policy_to_test.name)
|
2014-08-11 17:09:48 +01:00
|
|
|
else:
|
2015-02-25 17:33:44 +00:00
|
|
|
policy_to_test = policies.default
|
|
|
|
_info('Defaulting to policy %s' % policy_to_test.name)
|
|
|
|
|
|
|
|
# make policy_to_test be policy index 0 and default for the test config
|
|
|
|
sp_zero_section = sp_prefix + '0'
|
|
|
|
conf.add_section(sp_zero_section)
|
2014-06-30 11:14:28 -07:00
|
|
|
for (k, v) in policy_to_test.get_info(config=True).items():
|
2019-03-01 12:13:27 -08:00
|
|
|
conf.set(sp_zero_section, k, str(v))
|
|
|
|
conf.set(sp_zero_section, 'default', 'True')
|
2015-02-25 17:33:44 +00:00
|
|
|
|
|
|
|
with open(swift_conf, 'w') as fp:
|
|
|
|
conf.write(fp)
|
|
|
|
|
|
|
|
# look for a source ring file
|
|
|
|
ring_file_src = ring_file_test = 'object.ring.gz'
|
|
|
|
if policy_to_test.idx:
|
|
|
|
ring_file_src = 'object-%s.ring.gz' % policy_to_test.idx
|
|
|
|
try:
|
|
|
|
ring_file_src = _in_process_find_conf_file(conf_src_dir, ring_file_src,
|
|
|
|
use_sample=False)
|
2020-04-03 10:53:34 +02:00
|
|
|
except InProcessException:
|
2015-02-25 17:33:44 +00:00
|
|
|
if policy_specified:
|
|
|
|
raise InProcessException('Failed to find ring file %s'
|
|
|
|
% ring_file_src)
|
|
|
|
ring_file_src = None
|
|
|
|
|
|
|
|
ring_file_test = os.path.join(testdir, ring_file_test)
|
|
|
|
if ring_file_src:
|
|
|
|
# copy source ring file to a policy-0 test ring file, re-homing servers
|
|
|
|
_info('Using source ring file %s' % ring_file_src)
|
|
|
|
ring_data = ring.RingData.load(ring_file_src)
|
|
|
|
obj_sockets = []
|
|
|
|
for dev in ring_data.devs:
|
|
|
|
device = 'sd%c1' % chr(len(obj_sockets) + ord('a'))
|
|
|
|
utils.mkdirs(os.path.join(_testdir, 'sda1'))
|
|
|
|
utils.mkdirs(os.path.join(_testdir, 'sda1', 'tmp'))
|
2017-05-11 01:39:14 -06:00
|
|
|
obj_socket = listen_zero()
|
2015-02-25 17:33:44 +00:00
|
|
|
obj_sockets.append(obj_socket)
|
|
|
|
dev['port'] = obj_socket.getsockname()[1]
|
|
|
|
dev['ip'] = '127.0.0.1'
|
|
|
|
dev['device'] = device
|
|
|
|
dev['replication_port'] = dev['port']
|
|
|
|
dev['replication_ip'] = dev['ip']
|
|
|
|
ring_data.save(ring_file_test)
|
|
|
|
else:
|
2017-03-07 19:22:01 +00:00
|
|
|
# make default test ring, 3 replicas, 4 partitions, 3 devices
|
|
|
|
# which will work for a replication policy or a 2+1 EC policy
|
|
|
|
_info('No source object ring file, creating 3rep/4part/3dev ring')
|
2017-05-11 01:39:14 -06:00
|
|
|
obj_sockets = [listen_zero() for _ in (0, 1, 2)]
|
2017-03-07 19:22:01 +00:00
|
|
|
replica2part2dev_id = [[0, 1, 2, 0],
|
|
|
|
[1, 2, 0, 1],
|
|
|
|
[2, 0, 1, 2]]
|
|
|
|
devs = [{'id': 0, 'zone': 0, 'device': 'sda1', 'ip': '127.0.0.1',
|
|
|
|
'port': obj_sockets[0].getsockname()[1]},
|
|
|
|
{'id': 1, 'zone': 1, 'device': 'sdb1', 'ip': '127.0.0.1',
|
|
|
|
'port': obj_sockets[1].getsockname()[1]},
|
|
|
|
{'id': 2, 'zone': 2, 'device': 'sdc1', 'ip': '127.0.0.1',
|
|
|
|
'port': obj_sockets[2].getsockname()[1]}]
|
|
|
|
ring_data = ring.RingData(replica2part2dev_id, devs, 30)
|
2015-02-25 17:33:44 +00:00
|
|
|
with closing(GzipFile(ring_file_test, 'wb')) as f:
|
|
|
|
pickle.dump(ring_data, f)
|
|
|
|
|
|
|
|
for dev in ring_data.devs:
|
|
|
|
_debug('Ring file dev: %s' % dev)
|
|
|
|
|
|
|
|
return obj_sockets
|
|
|
|
|
|
|
|
|
2017-03-07 19:22:01 +00:00
|
|
|
def _load_encryption(proxy_conf_file, swift_conf_file, **kwargs):
|
2016-07-25 22:07:15 -05:00
|
|
|
"""
|
|
|
|
Load encryption configuration and override proxy-server.conf contents.
|
|
|
|
|
|
|
|
:param proxy_conf_file: Source proxy conf filename
|
2017-03-07 19:22:01 +00:00
|
|
|
:param swift_conf_file: Source swift conf filename
|
|
|
|
:returns: Tuple of paths to the proxy conf file and swift conf file to use
|
2016-07-25 22:07:15 -05:00
|
|
|
:raises InProcessException: raised if proxy conf contents are invalid
|
|
|
|
"""
|
|
|
|
_debug('Setting configuration for encryption')
|
|
|
|
|
|
|
|
# The global conf dict cannot be used to modify the pipeline.
|
|
|
|
# The pipeline loader requires the pipeline to be set in the local_conf.
|
|
|
|
# If pipeline is set in the global conf dict (which in turn populates the
|
|
|
|
# DEFAULTS options) then it prevents pipeline being loaded into the local
|
|
|
|
# conf during wsgi load_app.
|
|
|
|
# Therefore we must modify the [pipeline:main] section.
|
|
|
|
|
|
|
|
conf = ConfigParser()
|
|
|
|
conf.read(proxy_conf_file)
|
|
|
|
try:
|
|
|
|
section = 'pipeline:main'
|
|
|
|
pipeline = conf.get(section, 'pipeline')
|
|
|
|
pipeline = pipeline.replace(
|
|
|
|
"proxy-logging proxy-server",
|
|
|
|
"keymaster encryption proxy-logging proxy-server")
|
2019-11-19 21:25:45 -08:00
|
|
|
pipeline = pipeline.replace(
|
|
|
|
"cache listing_formats",
|
|
|
|
"cache etag-quoter listing_formats")
|
2016-07-25 22:07:15 -05:00
|
|
|
conf.set(section, 'pipeline', pipeline)
|
2019-08-06 10:00:41 -07:00
|
|
|
root_secret = base64.b64encode(os.urandom(32))
|
|
|
|
if not six.PY2:
|
|
|
|
root_secret = root_secret.decode('ascii')
|
2016-07-25 22:07:15 -05:00
|
|
|
conf.set('filter:keymaster', 'encryption_root_secret', root_secret)
|
2019-09-13 12:25:24 -05:00
|
|
|
conf.set('filter:versioned_writes', 'allow_object_versioning', 'true')
|
2019-11-19 21:25:45 -08:00
|
|
|
conf.set('filter:etag-quoter', 'enable_by_default', 'true')
|
2016-07-25 22:07:15 -05:00
|
|
|
except NoSectionError as err:
|
|
|
|
msg = 'Error problem with proxy conf file %s: %s' % \
|
|
|
|
(proxy_conf_file, err)
|
|
|
|
raise InProcessException(msg)
|
|
|
|
|
|
|
|
test_conf_file = os.path.join(_testdir, 'proxy-server.conf')
|
|
|
|
with open(test_conf_file, 'w') as fp:
|
|
|
|
conf.write(fp)
|
|
|
|
|
2017-03-07 19:22:01 +00:00
|
|
|
return test_conf_file, swift_conf_file
|
|
|
|
|
|
|
|
|
|
|
|
def _load_ec_as_default_policy(proxy_conf_file, swift_conf_file, **kwargs):
|
|
|
|
"""
|
|
|
|
Override swift.conf [storage-policy:0] section to use a 2+1 EC policy.
|
|
|
|
|
|
|
|
:param proxy_conf_file: Source proxy conf filename
|
|
|
|
:param swift_conf_file: Source swift conf filename
|
|
|
|
:returns: Tuple of paths to the proxy conf file and swift conf file to use
|
|
|
|
"""
|
|
|
|
_debug('Setting configuration for default EC policy')
|
|
|
|
|
|
|
|
conf = ConfigParser()
|
|
|
|
conf.read(swift_conf_file)
|
|
|
|
# remove existing policy sections that came with swift.conf-sample
|
|
|
|
for section in list(conf.sections()):
|
|
|
|
if section.startswith('storage-policy'):
|
|
|
|
conf.remove_section(section)
|
|
|
|
# add new policy 0 section for an EC policy
|
|
|
|
conf.add_section('storage-policy:0')
|
|
|
|
ec_policy_spec = {
|
|
|
|
'name': 'ec-test',
|
|
|
|
'policy_type': 'erasure_coding',
|
|
|
|
'ec_type': 'liberasurecode_rs_vand',
|
|
|
|
'ec_num_data_fragments': 2,
|
|
|
|
'ec_num_parity_fragments': 1,
|
|
|
|
'ec_object_segment_size': 1048576,
|
|
|
|
'default': True
|
|
|
|
}
|
|
|
|
|
|
|
|
for k, v in ec_policy_spec.items():
|
|
|
|
conf.set('storage-policy:0', k, str(v))
|
|
|
|
|
|
|
|
with open(swift_conf_file, 'w') as fp:
|
|
|
|
conf.write(fp)
|
|
|
|
return proxy_conf_file, swift_conf_file
|
2016-07-25 22:07:15 -05:00
|
|
|
|
|
|
|
|
2017-02-25 18:50:50 +01:00
|
|
|
def _load_domain_remap_staticweb(proxy_conf_file, swift_conf_file, **kwargs):
|
|
|
|
"""
|
|
|
|
Load domain_remap and staticweb into proxy server pipeline.
|
|
|
|
|
|
|
|
:param proxy_conf_file: Source proxy conf filename
|
|
|
|
:param swift_conf_file: Source swift conf filename
|
|
|
|
:returns: Tuple of paths to the proxy conf file and swift conf file to use
|
|
|
|
:raises InProcessException: raised if proxy conf contents are invalid
|
|
|
|
"""
|
|
|
|
_debug('Setting configuration for domain_remap')
|
|
|
|
|
2018-06-07 11:35:34 +01:00
|
|
|
# add a domain_remap storage_domain to the test configuration
|
|
|
|
storage_domain = 'example.net'
|
|
|
|
global config
|
|
|
|
config['storage_domain'] = storage_domain
|
|
|
|
|
2017-02-25 18:50:50 +01:00
|
|
|
# The global conf dict cannot be used to modify the pipeline.
|
|
|
|
# The pipeline loader requires the pipeline to be set in the local_conf.
|
|
|
|
# If pipeline is set in the global conf dict (which in turn populates the
|
|
|
|
# DEFAULTS options) then it prevents pipeline being loaded into the local
|
|
|
|
# conf during wsgi load_app.
|
|
|
|
# Therefore we must modify the [pipeline:main] section.
|
|
|
|
conf = ConfigParser()
|
|
|
|
conf.read(proxy_conf_file)
|
|
|
|
try:
|
|
|
|
section = 'pipeline:main'
|
|
|
|
old_pipeline = conf.get(section, 'pipeline')
|
|
|
|
pipeline = old_pipeline.replace(
|
2018-06-07 11:35:34 +01:00
|
|
|
" tempauth ",
|
2019-03-26 13:02:24 -07:00
|
|
|
" tempauth staticweb ")
|
|
|
|
pipeline = pipeline.replace(
|
|
|
|
" listing_formats ",
|
|
|
|
" domain_remap listing_formats ")
|
2017-02-25 18:50:50 +01:00
|
|
|
if pipeline == old_pipeline:
|
|
|
|
raise InProcessException(
|
|
|
|
"Failed to insert domain_remap and staticweb into pipeline: %s"
|
|
|
|
% old_pipeline)
|
|
|
|
conf.set(section, 'pipeline', pipeline)
|
2018-06-07 11:35:34 +01:00
|
|
|
# set storage_domain in domain_remap middleware to match test config
|
|
|
|
section = 'filter:domain_remap'
|
|
|
|
conf.set(section, 'storage_domain', storage_domain)
|
2017-02-25 18:50:50 +01:00
|
|
|
except NoSectionError as err:
|
|
|
|
msg = 'Error problem with proxy conf file %s: %s' % \
|
|
|
|
(proxy_conf_file, err)
|
|
|
|
raise InProcessException(msg)
|
|
|
|
|
|
|
|
test_conf_file = os.path.join(_testdir, 'proxy-server.conf')
|
|
|
|
with open(test_conf_file, 'w') as fp:
|
|
|
|
conf.write(fp)
|
|
|
|
|
|
|
|
return test_conf_file, swift_conf_file
|
|
|
|
|
|
|
|
|
2017-10-16 21:39:12 +09:00
|
|
|
def _load_s3api(proxy_conf_file, swift_conf_file, **kwargs):
|
|
|
|
"""
|
|
|
|
Load s3api configuration and override proxy-server.conf contents.
|
|
|
|
|
|
|
|
:param proxy_conf_file: Source proxy conf filename
|
|
|
|
:param swift_conf_file: Source swift conf filename
|
|
|
|
:returns: Tuple of paths to the proxy conf file and swift conf file to use
|
|
|
|
:raises InProcessException: raised if proxy conf contents are invalid
|
|
|
|
"""
|
|
|
|
_debug('Setting configuration for s3api')
|
|
|
|
|
|
|
|
# The global conf dict cannot be used to modify the pipeline.
|
|
|
|
# The pipeline loader requires the pipeline to be set in the local_conf.
|
|
|
|
# If pipeline is set in the global conf dict (which in turn populates the
|
|
|
|
# DEFAULTS options) then it prevents pipeline being loaded into the local
|
|
|
|
# conf during wsgi load_app.
|
|
|
|
# Therefore we must modify the [pipeline:main] section.
|
|
|
|
|
|
|
|
conf = ConfigParser()
|
|
|
|
conf.read(proxy_conf_file)
|
|
|
|
try:
|
|
|
|
section = 'pipeline:main'
|
|
|
|
pipeline = conf.get(section, 'pipeline')
|
|
|
|
pipeline = pipeline.replace(
|
|
|
|
"tempauth",
|
|
|
|
"s3api tempauth")
|
|
|
|
conf.set(section, 'pipeline', pipeline)
|
|
|
|
conf.set('filter:s3api', 's3_acl', 'true')
|
2019-09-13 12:25:24 -05:00
|
|
|
|
|
|
|
conf.set('filter:versioned_writes', 'allow_object_versioning', 'true')
|
2017-10-16 21:39:12 +09:00
|
|
|
except NoSectionError as err:
|
|
|
|
msg = 'Error problem with proxy conf file %s: %s' % \
|
|
|
|
(proxy_conf_file, err)
|
|
|
|
raise InProcessException(msg)
|
|
|
|
|
|
|
|
test_conf_file = os.path.join(_testdir, 'proxy-server.conf')
|
|
|
|
with open(test_conf_file, 'w') as fp:
|
|
|
|
conf.write(fp)
|
|
|
|
|
|
|
|
return test_conf_file, swift_conf_file
|
|
|
|
|
|
|
|
|
2016-07-25 22:07:15 -05:00
|
|
|
# Mapping from possible values of the variable
|
|
|
|
# SWIFT_TEST_IN_PROCESS_CONF_LOADER
|
|
|
|
# to the method to call for loading the associated configuration
|
|
|
|
# The expected signature for these methods is:
|
|
|
|
# conf_filename_to_use loader(input_conf_filename, **kwargs)
|
|
|
|
conf_loaders = {
|
2017-03-07 19:22:01 +00:00
|
|
|
'encryption': _load_encryption,
|
2017-02-25 18:50:50 +01:00
|
|
|
'ec': _load_ec_as_default_policy,
|
2016-07-25 22:07:15 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2015-02-25 17:33:44 +00:00
|
|
|
def in_process_setup(the_object_server=object_server):
|
|
|
|
_info('IN-PROCESS SERVERS IN USE FOR FUNCTIONAL TESTS')
|
|
|
|
_info('Using object_server class: %s' % the_object_server.__name__)
|
|
|
|
conf_src_dir = os.environ.get('SWIFT_TEST_IN_PROCESS_CONF_DIR')
|
2015-08-07 18:14:13 -05:00
|
|
|
show_debug_logs = os.environ.get('SWIFT_TEST_DEBUG_LOGS')
|
2015-02-25 17:33:44 +00:00
|
|
|
|
|
|
|
if conf_src_dir is not None:
|
|
|
|
if not os.path.isdir(conf_src_dir):
|
|
|
|
msg = 'Config source %s is not a dir' % conf_src_dir
|
|
|
|
raise InProcessException(msg)
|
|
|
|
_info('Using config source dir: %s' % conf_src_dir)
|
|
|
|
|
|
|
|
# If SWIFT_TEST_IN_PROCESS_CONF specifies a config source dir then
|
|
|
|
# prefer config files from there, otherwise read config from source tree
|
|
|
|
# sample files. A mixture of files from the two sources is allowed.
|
|
|
|
proxy_conf = _in_process_find_conf_file(conf_src_dir, 'proxy-server.conf')
|
|
|
|
_info('Using proxy config from %s' % proxy_conf)
|
|
|
|
swift_conf_src = _in_process_find_conf_file(conf_src_dir, 'swift.conf')
|
|
|
|
_info('Using swift config from %s' % swift_conf_src)
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
|
|
|
|
global _testdir
|
|
|
|
_testdir = os.path.join(mkdtemp(), 'tmp_functional')
|
|
|
|
utils.mkdirs(_testdir)
|
|
|
|
rmtree(_testdir)
|
|
|
|
utils.mkdirs(os.path.join(_testdir, 'sda1'))
|
|
|
|
utils.mkdirs(os.path.join(_testdir, 'sda1', 'tmp'))
|
|
|
|
utils.mkdirs(os.path.join(_testdir, 'sdb1'))
|
|
|
|
utils.mkdirs(os.path.join(_testdir, 'sdb1', 'tmp'))
|
2017-03-07 19:22:01 +00:00
|
|
|
utils.mkdirs(os.path.join(_testdir, 'sdc1'))
|
|
|
|
utils.mkdirs(os.path.join(_testdir, 'sdc1', 'tmp'))
|
|
|
|
|
|
|
|
swift_conf = _in_process_setup_swift_conf(swift_conf_src, _testdir)
|
2016-07-20 09:51:24 +00:00
|
|
|
_info('prepared swift.conf: %s' % swift_conf)
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
|
2019-10-28 22:10:42 +02:00
|
|
|
# load s3api and staticweb configs
|
|
|
|
proxy_conf, swift_conf = _load_s3api(proxy_conf, swift_conf)
|
|
|
|
proxy_conf, swift_conf = _load_domain_remap_staticweb(proxy_conf,
|
|
|
|
swift_conf)
|
|
|
|
|
2016-07-25 22:07:15 -05:00
|
|
|
# Call the associated method for the value of
|
|
|
|
# 'SWIFT_TEST_IN_PROCESS_CONF_LOADER', if one exists
|
|
|
|
conf_loader_label = os.environ.get(
|
|
|
|
'SWIFT_TEST_IN_PROCESS_CONF_LOADER')
|
|
|
|
if conf_loader_label is not None:
|
|
|
|
try:
|
|
|
|
conf_loader = conf_loaders[conf_loader_label]
|
|
|
|
_debug('Calling method %s mapped to conf loader %s' %
|
|
|
|
(conf_loader.__name__, conf_loader_label))
|
|
|
|
except KeyError as missing_key:
|
|
|
|
raise InProcessException('No function mapped for conf loader %s' %
|
|
|
|
missing_key)
|
|
|
|
|
|
|
|
try:
|
2017-03-07 19:22:01 +00:00
|
|
|
# Pass-in proxy_conf, swift_conf files
|
|
|
|
proxy_conf, swift_conf = conf_loader(proxy_conf, swift_conf)
|
2016-07-25 22:07:15 -05:00
|
|
|
_debug('Now using proxy conf %s' % proxy_conf)
|
2017-03-07 19:22:01 +00:00
|
|
|
_debug('Now using swift conf %s' % swift_conf)
|
2016-07-25 22:07:15 -05:00
|
|
|
except Exception as err: # noqa
|
|
|
|
raise InProcessException(err)
|
|
|
|
|
2015-02-25 17:33:44 +00:00
|
|
|
obj_sockets = _in_process_setup_ring(swift_conf, conf_src_dir, _testdir)
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
|
2016-07-20 09:51:24 +00:00
|
|
|
# load new swift.conf file
|
|
|
|
if set_swift_dir(os.path.dirname(swift_conf)):
|
|
|
|
constraints.reload_constraints()
|
|
|
|
storage_policy.reload_storage_policies()
|
|
|
|
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
global config
|
|
|
|
if constraints.SWIFT_CONSTRAINTS_LOADED:
|
|
|
|
# Use the swift constraints that are loaded for the test framework
|
|
|
|
# configuration
|
2014-08-11 17:09:48 +01:00
|
|
|
_c = dict((k, str(v))
|
|
|
|
for k, v in constraints.EFFECTIVE_CONSTRAINTS.items())
|
|
|
|
config.update(_c)
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
else:
|
|
|
|
# In-process swift constraints were not loaded, somethings wrong
|
|
|
|
raise SkipTest
|
|
|
|
|
2015-08-07 18:14:13 -05:00
|
|
|
global _test_socks
|
|
|
|
_test_socks = []
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
# We create the proxy server listening socket to get its port number so
|
|
|
|
# that we can add it as the "auth_port" value for the functional test
|
|
|
|
# clients.
|
2017-05-11 01:39:14 -06:00
|
|
|
prolis = listen_zero()
|
2015-08-07 18:14:13 -05:00
|
|
|
_test_socks.append(prolis)
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
|
|
|
|
# The following set of configuration values is used both for the
|
|
|
|
# functional test frame work and for the various proxy, account, container
|
|
|
|
# and object servers.
|
|
|
|
config.update({
|
|
|
|
# Values needed by the various in-process swift servers
|
|
|
|
'devices': _testdir,
|
|
|
|
'swift_dir': _testdir,
|
|
|
|
'mount_check': 'false',
|
2014-08-11 17:09:48 +01:00
|
|
|
'client_timeout': '4',
|
2020-11-05 17:36:26 -08:00
|
|
|
'container_update_timeout': '3',
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
'allow_account_management': 'true',
|
|
|
|
'account_autocreate': 'true',
|
|
|
|
'allow_versions': 'True',
|
2016-08-26 00:15:45 -07:00
|
|
|
'allow_versioned_writes': 'True',
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
# Below are values used by the functional test framework, as well as
|
|
|
|
# by the various in-process swift servers
|
2019-03-01 12:43:42 -08:00
|
|
|
'auth_uri': 'http://127.0.0.1:%d/auth/v1.0/' % prolis.getsockname()[1],
|
2018-05-29 16:57:57 -04:00
|
|
|
's3_storage_url': 'http://%s:%d/' % prolis.getsockname(),
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
# Primary functional test account (needs admin access to the
|
|
|
|
# account)
|
|
|
|
'account': 'test',
|
|
|
|
'username': 'tester',
|
|
|
|
'password': 'testing',
|
2017-10-16 21:39:12 +09:00
|
|
|
's3_access_key': 'test:tester',
|
|
|
|
's3_secret_key': 'testing',
|
2018-09-13 11:38:01 -06:00
|
|
|
# Secondary user of the primary test account (needs admin access
|
|
|
|
# to the account) for s3api
|
|
|
|
's3_access_key2': 'test:tester2',
|
|
|
|
's3_secret_key2': 'testing2',
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
# User on a second account (needs admin access to the account)
|
|
|
|
'account2': 'test2',
|
|
|
|
'username2': 'tester2',
|
|
|
|
'password2': 'testing2',
|
|
|
|
# User on same account as first, but without admin access
|
|
|
|
'username3': 'tester3',
|
|
|
|
'password3': 'testing3',
|
2018-09-13 11:38:01 -06:00
|
|
|
's3_access_key3': 'test:tester3',
|
|
|
|
's3_secret_key3': 'testing3',
|
2014-11-25 14:42:42 +00:00
|
|
|
# Service user and prefix (emulates glance, cinder, etc. user)
|
|
|
|
'account5': 'test5',
|
|
|
|
'username5': 'tester5',
|
|
|
|
'password5': 'testing5',
|
|
|
|
'service_prefix': 'SERVICE',
|
|
|
|
# For tempauth middleware. Update reseller_prefix
|
|
|
|
'reseller_prefix': 'AUTH, SERVICE',
|
2015-07-16 09:35:37 +09:00
|
|
|
'SERVICE_require_group': 'service',
|
|
|
|
# Reseller admin user (needs reseller_admin_role)
|
|
|
|
'account6': 'test6',
|
|
|
|
'username6': 'tester6',
|
|
|
|
'password6': 'testing6'
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
})
|
|
|
|
|
2017-05-11 01:39:14 -06:00
|
|
|
acc1lis = listen_zero()
|
|
|
|
acc2lis = listen_zero()
|
|
|
|
con1lis = listen_zero()
|
|
|
|
con2lis = listen_zero()
|
2015-08-07 18:14:13 -05:00
|
|
|
_test_socks += [acc1lis, acc2lis, con1lis, con2lis] + obj_sockets
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
|
|
|
|
account_ring_path = os.path.join(_testdir, 'account.ring.gz')
|
|
|
|
with closing(GzipFile(account_ring_path, 'wb')) as f:
|
|
|
|
pickle.dump(ring.RingData([[0, 1, 0, 1], [1, 0, 1, 0]],
|
|
|
|
[{'id': 0, 'zone': 0, 'device': 'sda1', 'ip': '127.0.0.1',
|
|
|
|
'port': acc1lis.getsockname()[1]},
|
|
|
|
{'id': 1, 'zone': 1, 'device': 'sdb1', 'ip': '127.0.0.1',
|
|
|
|
'port': acc2lis.getsockname()[1]}], 30),
|
|
|
|
f)
|
|
|
|
container_ring_path = os.path.join(_testdir, 'container.ring.gz')
|
|
|
|
with closing(GzipFile(container_ring_path, 'wb')) as f:
|
|
|
|
pickle.dump(ring.RingData([[0, 1, 0, 1], [1, 0, 1, 0]],
|
|
|
|
[{'id': 0, 'zone': 0, 'device': 'sda1', 'ip': '127.0.0.1',
|
|
|
|
'port': con1lis.getsockname()[1]},
|
|
|
|
{'id': 1, 'zone': 1, 'device': 'sdb1', 'ip': '127.0.0.1',
|
|
|
|
'port': con2lis.getsockname()[1]}], 30),
|
|
|
|
f)
|
|
|
|
|
2015-08-07 18:14:13 -05:00
|
|
|
def get_logger_name(name):
|
|
|
|
if show_debug_logs:
|
|
|
|
return debug_logger(name)
|
|
|
|
else:
|
|
|
|
return None
|
|
|
|
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
acc1srv = account_server.AccountController(
|
2015-08-07 18:14:13 -05:00
|
|
|
config, logger=get_logger_name('acct1'))
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
acc2srv = account_server.AccountController(
|
2015-08-07 18:14:13 -05:00
|
|
|
config, logger=get_logger_name('acct2'))
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
con1srv = container_server.ContainerController(
|
2015-08-07 18:14:13 -05:00
|
|
|
config, logger=get_logger_name('cont1'))
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
con2srv = container_server.ContainerController(
|
2015-08-07 18:14:13 -05:00
|
|
|
config, logger=get_logger_name('cont2'))
|
2015-02-25 17:33:44 +00:00
|
|
|
|
|
|
|
objsrvs = [
|
|
|
|
(obj_sockets[index],
|
|
|
|
the_object_server.ObjectController(
|
2015-08-07 18:14:13 -05:00
|
|
|
config, logger=get_logger_name('obj%d' % (index + 1))))
|
2015-02-25 17:33:44 +00:00
|
|
|
for index in range(len(obj_sockets))
|
|
|
|
]
|
2014-08-11 17:09:48 +01:00
|
|
|
|
2015-08-07 18:14:13 -05:00
|
|
|
if show_debug_logs:
|
2016-09-20 16:38:45 -07:00
|
|
|
logger = get_logger_name('proxy')
|
|
|
|
else:
|
|
|
|
logger = utils.get_logger(config, 'wsgi-server', log_route='wsgi')
|
2014-08-11 17:09:48 +01:00
|
|
|
|
|
|
|
def get_logger(name, *args, **kwargs):
|
|
|
|
return logger
|
|
|
|
|
|
|
|
with mock.patch('swift.common.utils.get_logger', get_logger):
|
|
|
|
with mock.patch('swift.common.middleware.memcache.MemcacheMiddleware',
|
|
|
|
FakeMemcacheMiddleware):
|
2015-02-25 17:33:44 +00:00
|
|
|
try:
|
|
|
|
app = loadapp(proxy_conf, global_conf=config)
|
|
|
|
except Exception as e:
|
|
|
|
raise InProcessException(e)
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
|
|
|
|
nl = utils.NullLogger()
|
2015-08-07 18:14:13 -05:00
|
|
|
global proxy_srv
|
|
|
|
proxy_srv = prolis
|
2016-09-20 16:38:45 -07:00
|
|
|
prospa = eventlet.spawn(eventlet.wsgi.server, prolis, app, nl,
|
|
|
|
protocol=SwiftHttpProtocol)
|
|
|
|
acc1spa = eventlet.spawn(eventlet.wsgi.server, acc1lis, acc1srv, nl,
|
|
|
|
protocol=SwiftHttpProtocol)
|
|
|
|
acc2spa = eventlet.spawn(eventlet.wsgi.server, acc2lis, acc2srv, nl,
|
|
|
|
protocol=SwiftHttpProtocol)
|
|
|
|
con1spa = eventlet.spawn(eventlet.wsgi.server, con1lis, con1srv, nl,
|
|
|
|
protocol=SwiftHttpProtocol)
|
|
|
|
con2spa = eventlet.spawn(eventlet.wsgi.server, con2lis, con2srv, nl,
|
|
|
|
protocol=SwiftHttpProtocol)
|
|
|
|
|
|
|
|
objspa = [eventlet.spawn(eventlet.wsgi.server, objsrv[0], objsrv[1], nl,
|
|
|
|
protocol=SwiftHttpProtocol)
|
2015-02-25 17:33:44 +00:00
|
|
|
for objsrv in objsrvs]
|
|
|
|
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
global _test_coros
|
|
|
|
_test_coros = \
|
2015-02-25 17:33:44 +00:00
|
|
|
(prospa, acc1spa, acc2spa, con1spa, con2spa) + tuple(objspa)
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
|
|
|
|
# Create accounts "test" and "test2"
|
|
|
|
def create_account(act):
|
|
|
|
ts = utils.normalize_timestamp(time())
|
2014-08-11 17:09:48 +01:00
|
|
|
account_ring = Ring(_testdir, ring_name='account')
|
|
|
|
partition, nodes = account_ring.get_nodes(act)
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
for node in nodes:
|
|
|
|
# Note: we are just using the http_connect method in the object
|
|
|
|
# controller here to talk to the account server nodes.
|
|
|
|
conn = swift.proxy.controllers.obj.http_connect(
|
|
|
|
node['ip'], node['port'], node['device'], partition, 'PUT',
|
|
|
|
'/' + act, {'X-Timestamp': ts, 'x-trans-id': act})
|
|
|
|
resp = conn.getresponse()
|
2017-05-04 17:48:22 +00:00
|
|
|
assert resp.status == 201, 'Unable to create account: %s\n%s' % (
|
2019-03-01 12:13:27 -08:00
|
|
|
resp.status, resp.read())
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
|
|
|
|
create_account('AUTH_test')
|
|
|
|
create_account('AUTH_test2')
|
2014-03-31 22:56:17 -04:00
|
|
|
|
2020-04-03 10:44:25 -07:00
|
|
|
|
2014-04-10 15:37:15 -04:00
|
|
|
cluster_info = {}
|
|
|
|
|
|
|
|
|
|
|
|
def get_cluster_info():
|
|
|
|
# The fallback constraints used for testing will come from the current
|
|
|
|
# effective constraints.
|
|
|
|
eff_constraints = dict(constraints.EFFECTIVE_CONSTRAINTS)
|
|
|
|
|
|
|
|
# We'll update those constraints based on what the /info API provides, if
|
|
|
|
# anything.
|
|
|
|
global cluster_info
|
2015-08-07 18:14:13 -05:00
|
|
|
global config
|
2014-04-10 15:37:15 -04:00
|
|
|
try:
|
|
|
|
conn = Connection(config)
|
|
|
|
conn.authenticate()
|
|
|
|
cluster_info.update(conn.cluster_info())
|
2017-01-27 07:43:37 -08:00
|
|
|
except (ResponseError, socket.error, SkipTest):
|
2014-04-10 15:37:15 -04:00
|
|
|
# Failed to get cluster_information via /info API, so fall back on
|
|
|
|
# test.conf data
|
|
|
|
pass
|
|
|
|
else:
|
2014-06-02 13:36:21 -04:00
|
|
|
try:
|
|
|
|
eff_constraints.update(cluster_info['swift'])
|
|
|
|
except KeyError:
|
|
|
|
# Most likely the swift cluster has "expose_info = false" set
|
|
|
|
# in its proxy-server.conf file, so we'll just do the best we
|
|
|
|
# can.
|
2015-07-28 20:35:25 +05:30
|
|
|
print("** Swift Cluster not exposing /info **", file=sys.stderr)
|
2014-04-10 15:37:15 -04:00
|
|
|
|
|
|
|
# Finally, we'll allow any constraint present in the swift-constraints
|
|
|
|
# section of test.conf to override everything. Note that only those
|
|
|
|
# constraints defined in the constraints module are converted to integers.
|
|
|
|
test_constraints = get_config('swift-constraints')
|
|
|
|
for k in constraints.DEFAULT_CONSTRAINTS:
|
|
|
|
try:
|
|
|
|
test_constraints[k] = int(test_constraints[k])
|
|
|
|
except KeyError:
|
|
|
|
pass
|
|
|
|
except ValueError:
|
2015-07-28 20:35:25 +05:30
|
|
|
print("Invalid constraint value: %s = %s" % (
|
|
|
|
k, test_constraints[k]), file=sys.stderr)
|
2014-04-10 15:37:15 -04:00
|
|
|
eff_constraints.update(test_constraints)
|
|
|
|
|
|
|
|
# Just make it look like these constraints were loaded from a /info call,
|
|
|
|
# even if the /info call failed, or when they are overridden by values
|
|
|
|
# from the swift-constraints section of test.conf
|
|
|
|
cluster_info['swift'] = eff_constraints
|
|
|
|
|
2014-03-31 22:56:17 -04:00
|
|
|
|
|
|
|
def setup_package():
|
2015-03-25 13:19:36 +00:00
|
|
|
|
|
|
|
global policy_specified
|
Add checksum to object extended attributes
Currently, our integrity checking for objects is pretty weak when it
comes to object metadata. If the extended attributes on a .data or
.meta file get corrupted in such a way that we can still unpickle it,
we don't have anything that detects that.
This could be especially bad with encrypted etags; if the encrypted
etag (X-Object-Sysmeta-Crypto-Etag or whatever it is) gets some bits
flipped, then we'll cheerfully decrypt the cipherjunk into plainjunk,
then send it to the client. Net effect is that the client sees a GET
response with an ETag that doesn't match the MD5 of the object *and*
Swift has no way of detecting and quarantining this object.
Note that, with an unencrypted object, if the ETag metadatum gets
mangled, then the object will be quarantined by the object server or
auditor, whichever notices first.
As part of this commit, I also ripped out some mocking of
getxattr/setxattr in tests. It appears to be there to allow unit tests
to run on systems where /tmp doesn't support xattrs. However, since
the mock is keyed off of inode number and inode numbers get re-used,
there's lots of leakage between different test runs. On a real FS,
unlinking a file and then creating a new one of the same name will
also reset the xattrs; this isn't the case with the mock.
The mock was pretty old; Ubuntu 12.04 and up all support xattrs in
/tmp, and recent Red Hat / CentOS releases do too. The xattr mock was
added in 2011; maybe it was to support Ubuntu Lucid Lynx?
Bonus: now you can pause a test with the debugger, inspect its files
in /tmp, and actually see the xattrs along with the data.
Since this patch now uses a real filesystem for testing filesystem
operations, tests are skipped if the underlying filesystem does not
support setting xattrs (eg tmpfs or more than 4k of xattrs on ext4).
References to "/tmp" have been replaced with calls to
tempfile.gettempdir(). This will allow setting the TMPDIR envvar in
test setup and getting an XFS filesystem instead of ext4 or tmpfs.
THIS PATCH SIGNIFICANTLY CHANGES TESTING ENVIRONMENTS
With this patch, every test environment will require TMPDIR to be
using a filesystem that supports at least 4k of extended attributes.
Neither ext4 nor tempfs support this. XFS is recommended.
So why all the SkipTests? Why not simply raise an error? We still need
the tests to run on the base image for OpenStack's CI system. Since
we were previously mocking out xattr, there wasn't a problem, but we
also weren't actually testing anything. This patch adds functionality
to validate xattr data, so we need to drop the mock.
`test.unit.skip_if_no_xattrs()` is also imported into `test.functional`
so that functional tests can import it from the functional test
namespace.
The related OpenStack CI infrastructure changes are made in
https://review.openstack.org/#/c/394600/.
Co-Authored-By: John Dickinson <me@not.mn>
Change-Id: I98a37c0d451f4960b7a12f648e4405c6c6716808
2016-06-30 16:52:58 -07:00
|
|
|
global skip_if_no_xattrs
|
2015-03-25 13:19:36 +00:00
|
|
|
policy_specified = os.environ.get('SWIFT_TEST_POLICY')
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
in_process_env = os.environ.get('SWIFT_TEST_IN_PROCESS')
|
|
|
|
if in_process_env is not None:
|
|
|
|
use_in_process = utils.config_true_value(in_process_env)
|
|
|
|
else:
|
|
|
|
use_in_process = None
|
|
|
|
|
|
|
|
global in_process
|
|
|
|
|
2015-08-07 18:14:13 -05:00
|
|
|
global config
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
if use_in_process:
|
|
|
|
# Explicitly set to True, so barrel on ahead with in-process
|
|
|
|
# functional test setup.
|
|
|
|
in_process = True
|
|
|
|
# NOTE: No attempt is made to a read local test.conf file.
|
|
|
|
else:
|
|
|
|
if use_in_process is None:
|
|
|
|
# Not explicitly set, default to using in-process functional tests
|
|
|
|
# if the test.conf file is not found, or does not provide a usable
|
|
|
|
# configuration.
|
|
|
|
config.update(get_config('func_test'))
|
2016-02-19 09:30:10 +00:00
|
|
|
if not config:
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
in_process = True
|
2016-02-19 09:30:10 +00:00
|
|
|
# else... leave in_process value unchanged. It may be that
|
|
|
|
# setup_package is called twice, in which case in_process_setup may
|
|
|
|
# have loaded config before we reach here a second time, so the
|
|
|
|
# existence of config is not reliable to determine that in_process
|
|
|
|
# should be False. Anyway, it's default value is False.
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
else:
|
|
|
|
# Explicitly set to False, do not attempt to use in-process
|
|
|
|
# functional tests, be sure we attempt to read from local
|
|
|
|
# test.conf file.
|
|
|
|
in_process = False
|
|
|
|
config.update(get_config('func_test'))
|
|
|
|
|
|
|
|
if in_process:
|
2014-05-06 10:54:05 -04:00
|
|
|
in_mem_obj_env = os.environ.get('SWIFT_TEST_IN_MEMORY_OBJ')
|
|
|
|
in_mem_obj = utils.config_true_value(in_mem_obj_env)
|
Add checksum to object extended attributes
Currently, our integrity checking for objects is pretty weak when it
comes to object metadata. If the extended attributes on a .data or
.meta file get corrupted in such a way that we can still unpickle it,
we don't have anything that detects that.
This could be especially bad with encrypted etags; if the encrypted
etag (X-Object-Sysmeta-Crypto-Etag or whatever it is) gets some bits
flipped, then we'll cheerfully decrypt the cipherjunk into plainjunk,
then send it to the client. Net effect is that the client sees a GET
response with an ETag that doesn't match the MD5 of the object *and*
Swift has no way of detecting and quarantining this object.
Note that, with an unencrypted object, if the ETag metadatum gets
mangled, then the object will be quarantined by the object server or
auditor, whichever notices first.
As part of this commit, I also ripped out some mocking of
getxattr/setxattr in tests. It appears to be there to allow unit tests
to run on systems where /tmp doesn't support xattrs. However, since
the mock is keyed off of inode number and inode numbers get re-used,
there's lots of leakage between different test runs. On a real FS,
unlinking a file and then creating a new one of the same name will
also reset the xattrs; this isn't the case with the mock.
The mock was pretty old; Ubuntu 12.04 and up all support xattrs in
/tmp, and recent Red Hat / CentOS releases do too. The xattr mock was
added in 2011; maybe it was to support Ubuntu Lucid Lynx?
Bonus: now you can pause a test with the debugger, inspect its files
in /tmp, and actually see the xattrs along with the data.
Since this patch now uses a real filesystem for testing filesystem
operations, tests are skipped if the underlying filesystem does not
support setting xattrs (eg tmpfs or more than 4k of xattrs on ext4).
References to "/tmp" have been replaced with calls to
tempfile.gettempdir(). This will allow setting the TMPDIR envvar in
test setup and getting an XFS filesystem instead of ext4 or tmpfs.
THIS PATCH SIGNIFICANTLY CHANGES TESTING ENVIRONMENTS
With this patch, every test environment will require TMPDIR to be
using a filesystem that supports at least 4k of extended attributes.
Neither ext4 nor tempfs support this. XFS is recommended.
So why all the SkipTests? Why not simply raise an error? We still need
the tests to run on the base image for OpenStack's CI system. Since
we were previously mocking out xattr, there wasn't a problem, but we
also weren't actually testing anything. This patch adds functionality
to validate xattr data, so we need to drop the mock.
`test.unit.skip_if_no_xattrs()` is also imported into `test.functional`
so that functional tests can import it from the functional test
namespace.
The related OpenStack CI infrastructure changes are made in
https://review.openstack.org/#/c/394600/.
Co-Authored-By: John Dickinson <me@not.mn>
Change-Id: I98a37c0d451f4960b7a12f648e4405c6c6716808
2016-06-30 16:52:58 -07:00
|
|
|
skip_if_no_xattrs = real_skip_if_no_xattrs
|
2015-02-25 17:33:44 +00:00
|
|
|
try:
|
|
|
|
in_process_setup(the_object_server=(
|
|
|
|
mem_object_server if in_mem_obj else object_server))
|
|
|
|
except InProcessException as exc:
|
2015-07-28 20:35:25 +05:30
|
|
|
print(('Exception during in-process setup: %s'
|
|
|
|
% str(exc)), file=sys.stderr)
|
2015-02-25 17:33:44 +00:00
|
|
|
raise
|
Add checksum to object extended attributes
Currently, our integrity checking for objects is pretty weak when it
comes to object metadata. If the extended attributes on a .data or
.meta file get corrupted in such a way that we can still unpickle it,
we don't have anything that detects that.
This could be especially bad with encrypted etags; if the encrypted
etag (X-Object-Sysmeta-Crypto-Etag or whatever it is) gets some bits
flipped, then we'll cheerfully decrypt the cipherjunk into plainjunk,
then send it to the client. Net effect is that the client sees a GET
response with an ETag that doesn't match the MD5 of the object *and*
Swift has no way of detecting and quarantining this object.
Note that, with an unencrypted object, if the ETag metadatum gets
mangled, then the object will be quarantined by the object server or
auditor, whichever notices first.
As part of this commit, I also ripped out some mocking of
getxattr/setxattr in tests. It appears to be there to allow unit tests
to run on systems where /tmp doesn't support xattrs. However, since
the mock is keyed off of inode number and inode numbers get re-used,
there's lots of leakage between different test runs. On a real FS,
unlinking a file and then creating a new one of the same name will
also reset the xattrs; this isn't the case with the mock.
The mock was pretty old; Ubuntu 12.04 and up all support xattrs in
/tmp, and recent Red Hat / CentOS releases do too. The xattr mock was
added in 2011; maybe it was to support Ubuntu Lucid Lynx?
Bonus: now you can pause a test with the debugger, inspect its files
in /tmp, and actually see the xattrs along with the data.
Since this patch now uses a real filesystem for testing filesystem
operations, tests are skipped if the underlying filesystem does not
support setting xattrs (eg tmpfs or more than 4k of xattrs on ext4).
References to "/tmp" have been replaced with calls to
tempfile.gettempdir(). This will allow setting the TMPDIR envvar in
test setup and getting an XFS filesystem instead of ext4 or tmpfs.
THIS PATCH SIGNIFICANTLY CHANGES TESTING ENVIRONMENTS
With this patch, every test environment will require TMPDIR to be
using a filesystem that supports at least 4k of extended attributes.
Neither ext4 nor tempfs support this. XFS is recommended.
So why all the SkipTests? Why not simply raise an error? We still need
the tests to run on the base image for OpenStack's CI system. Since
we were previously mocking out xattr, there wasn't a problem, but we
also weren't actually testing anything. This patch adds functionality
to validate xattr data, so we need to drop the mock.
`test.unit.skip_if_no_xattrs()` is also imported into `test.functional`
so that functional tests can import it from the functional test
namespace.
The related OpenStack CI infrastructure changes are made in
https://review.openstack.org/#/c/394600/.
Co-Authored-By: John Dickinson <me@not.mn>
Change-Id: I98a37c0d451f4960b7a12f648e4405c6c6716808
2016-06-30 16:52:58 -07:00
|
|
|
else:
|
|
|
|
skip_if_no_xattrs = lambda: None
|
2014-03-31 23:51:43 -04:00
|
|
|
|
|
|
|
global web_front_end
|
|
|
|
web_front_end = config.get('web_front_end', 'integral')
|
|
|
|
global normalized_urls
|
|
|
|
normalized_urls = config.get('normalized_urls', False)
|
|
|
|
|
2014-03-31 22:56:17 -04:00
|
|
|
global orig_collate
|
|
|
|
orig_collate = locale.setlocale(locale.LC_COLLATE)
|
|
|
|
locale.setlocale(locale.LC_COLLATE, config.get('collate', 'C'))
|
|
|
|
|
2014-04-30 12:17:25 -06:00
|
|
|
global insecure
|
|
|
|
insecure = config_true_value(config.get('insecure', False))
|
|
|
|
|
2014-03-31 23:51:43 -04:00
|
|
|
global swift_test_auth_version
|
|
|
|
global swift_test_auth
|
|
|
|
global swift_test_user
|
|
|
|
global swift_test_key
|
|
|
|
global swift_test_tenant
|
|
|
|
global swift_test_perm
|
2014-03-28 02:46:08 +00:00
|
|
|
global swift_test_domain
|
2014-11-25 14:42:42 +00:00
|
|
|
global swift_test_service_prefix
|
|
|
|
|
|
|
|
swift_test_service_prefix = None
|
2014-03-31 23:51:43 -04:00
|
|
|
|
|
|
|
if config:
|
|
|
|
swift_test_auth_version = str(config.get('auth_version', '1'))
|
|
|
|
|
2018-08-01 23:52:04 +00:00
|
|
|
if 'auth_uri' in config:
|
|
|
|
swift_test_auth = config['auth_uri']
|
|
|
|
# Back-fill the individual parts -- really, we should just need
|
|
|
|
# host and port for s3_test_client, and that's only until we
|
|
|
|
# improve it to take a s3_storage_url option
|
|
|
|
parsed = urlsplit(config['auth_uri'])
|
|
|
|
config.update({
|
2019-03-01 12:43:42 -08:00
|
|
|
'auth_ssl': str(parsed.scheme == 'https'),
|
2018-08-01 23:52:04 +00:00
|
|
|
'auth_host': parsed.hostname,
|
2019-03-01 12:43:42 -08:00
|
|
|
'auth_port': str(
|
|
|
|
parsed.port if parsed.port is not None else
|
|
|
|
443 if parsed.scheme == 'https' else 80),
|
2018-08-01 23:52:04 +00:00
|
|
|
'auth_prefix': parsed.path,
|
|
|
|
})
|
2018-05-29 16:57:57 -04:00
|
|
|
config.setdefault('s3_storage_url',
|
|
|
|
urlunsplit(parsed[:2] + ('', None, None)))
|
2018-08-01 23:52:04 +00:00
|
|
|
elif 'auth_host' in config:
|
|
|
|
scheme = 'http'
|
|
|
|
if config_true_value(config.get('auth_ssl', 'no')):
|
|
|
|
scheme = 'https'
|
|
|
|
netloc = config['auth_host']
|
|
|
|
if 'auth_port' in config:
|
|
|
|
netloc += ':' + config['auth_port']
|
|
|
|
auth_prefix = config.get('auth_prefix', '/')
|
|
|
|
if swift_test_auth_version == "1":
|
|
|
|
auth_prefix += 'v1.0'
|
|
|
|
config['auth_uri'] = swift_test_auth = urlunsplit(
|
|
|
|
(scheme, netloc, auth_prefix, None, None))
|
2018-05-29 16:57:57 -04:00
|
|
|
config.setdefault('s3_storage_url', urlunsplit(
|
|
|
|
(scheme, netloc, '', None, None)))
|
2018-08-01 23:52:04 +00:00
|
|
|
# else, neither auth_uri nor auth_host; swift_test_auth will be unset
|
|
|
|
# and we'll skip everything later
|
2014-03-31 23:51:43 -04:00
|
|
|
|
2014-11-25 14:42:42 +00:00
|
|
|
if 'service_prefix' in config:
|
2020-04-03 10:53:34 +02:00
|
|
|
swift_test_service_prefix = utils.append_underscore(
|
|
|
|
config['service_prefix'])
|
2014-11-25 14:42:42 +00:00
|
|
|
|
2014-03-31 23:51:43 -04:00
|
|
|
if swift_test_auth_version == "1":
|
|
|
|
|
|
|
|
try:
|
|
|
|
if 'account' in config:
|
|
|
|
swift_test_user[0] = '%(account)s:%(username)s' % config
|
|
|
|
else:
|
|
|
|
swift_test_user[0] = '%(username)s' % config
|
|
|
|
swift_test_key[0] = config['password']
|
|
|
|
except KeyError:
|
|
|
|
# bad config, no account/username configured, tests cannot be
|
|
|
|
# run
|
|
|
|
pass
|
|
|
|
try:
|
|
|
|
swift_test_user[1] = '%s%s' % (
|
|
|
|
'%s:' % config['account2'] if 'account2' in config else '',
|
|
|
|
config['username2'])
|
|
|
|
swift_test_key[1] = config['password2']
|
|
|
|
except KeyError:
|
|
|
|
pass # old config, no second account tests can be run
|
|
|
|
try:
|
|
|
|
swift_test_user[2] = '%s%s' % (
|
|
|
|
'%s:' % config['account'] if 'account'
|
|
|
|
in config else '', config['username3'])
|
|
|
|
swift_test_key[2] = config['password3']
|
|
|
|
except KeyError:
|
|
|
|
pass # old config, no third account tests can be run
|
2014-11-25 14:42:42 +00:00
|
|
|
try:
|
|
|
|
swift_test_user[4] = '%s%s' % (
|
|
|
|
'%s:' % config['account5'], config['username5'])
|
|
|
|
swift_test_key[4] = config['password5']
|
|
|
|
swift_test_tenant[4] = config['account5']
|
|
|
|
except KeyError:
|
|
|
|
pass # no service token tests can be run
|
2014-03-31 23:51:43 -04:00
|
|
|
|
|
|
|
for _ in range(3):
|
|
|
|
swift_test_perm[_] = swift_test_user[_]
|
|
|
|
|
|
|
|
else:
|
|
|
|
swift_test_user[0] = config['username']
|
|
|
|
swift_test_tenant[0] = config['account']
|
|
|
|
swift_test_key[0] = config['password']
|
2019-08-05 14:48:54 -07:00
|
|
|
if 'domain' in config:
|
|
|
|
swift_test_domain[0] = config['domain']
|
2014-03-31 23:51:43 -04:00
|
|
|
swift_test_user[1] = config['username2']
|
|
|
|
swift_test_tenant[1] = config['account2']
|
|
|
|
swift_test_key[1] = config['password2']
|
2019-08-05 14:48:54 -07:00
|
|
|
if 'domain2' in config:
|
|
|
|
swift_test_domain[1] = config['domain2']
|
2014-03-31 23:51:43 -04:00
|
|
|
swift_test_user[2] = config['username3']
|
|
|
|
swift_test_tenant[2] = config['account']
|
|
|
|
swift_test_key[2] = config['password3']
|
2019-08-05 14:48:54 -07:00
|
|
|
if 'domain3' in config:
|
|
|
|
swift_test_domain[2] = config['domain3']
|
2014-03-28 02:46:08 +00:00
|
|
|
if 'username4' in config:
|
|
|
|
swift_test_user[3] = config['username4']
|
|
|
|
swift_test_tenant[3] = config['account4']
|
|
|
|
swift_test_key[3] = config['password4']
|
|
|
|
swift_test_domain[3] = config['domain4']
|
2014-11-25 14:42:42 +00:00
|
|
|
if 'username5' in config:
|
|
|
|
swift_test_user[4] = config['username5']
|
|
|
|
swift_test_tenant[4] = config['account5']
|
|
|
|
swift_test_key[4] = config['password5']
|
2019-08-05 14:48:54 -07:00
|
|
|
if 'domain5' in config:
|
|
|
|
swift_test_domain[4] = config['domain5']
|
2015-07-16 09:35:37 +09:00
|
|
|
if 'username6' in config:
|
|
|
|
swift_test_user[5] = config['username6']
|
|
|
|
swift_test_tenant[5] = config['account6']
|
|
|
|
swift_test_key[5] = config['password6']
|
2019-08-05 14:48:54 -07:00
|
|
|
if 'domain6' in config:
|
|
|
|
swift_test_domain[5] = config['domain6']
|
2014-03-31 23:51:43 -04:00
|
|
|
|
2014-11-25 14:42:42 +00:00
|
|
|
for _ in range(5):
|
2014-03-31 23:51:43 -04:00
|
|
|
swift_test_perm[_] = swift_test_tenant[_] + ':' \
|
|
|
|
+ swift_test_user[_]
|
|
|
|
|
|
|
|
global skip
|
2018-10-30 23:04:19 +00:00
|
|
|
if not skip:
|
|
|
|
skip = not all([swift_test_auth, swift_test_user[0],
|
|
|
|
swift_test_key[0]])
|
|
|
|
if skip:
|
|
|
|
print('SKIPPING FUNCTIONAL TESTS DUE TO NO CONFIG',
|
|
|
|
file=sys.stderr)
|
2014-03-31 23:51:43 -04:00
|
|
|
|
|
|
|
global skip2
|
2018-10-30 23:04:19 +00:00
|
|
|
if not skip2:
|
|
|
|
skip2 = not all([not skip, swift_test_user[1], swift_test_key[1]])
|
|
|
|
if not skip and skip2:
|
|
|
|
print('SKIPPING SECOND ACCOUNT FUNCTIONAL TESTS '
|
|
|
|
'DUE TO NO CONFIG FOR THEM', file=sys.stderr)
|
2014-03-31 23:51:43 -04:00
|
|
|
|
|
|
|
global skip3
|
2018-10-30 23:04:19 +00:00
|
|
|
if not skip3:
|
|
|
|
skip3 = not all([not skip, swift_test_user[2], swift_test_key[2]])
|
|
|
|
if not skip and skip3:
|
|
|
|
print('SKIPPING THIRD ACCOUNT FUNCTIONAL TESTS '
|
|
|
|
'DUE TO NO CONFIG FOR THEM', file=sys.stderr)
|
2014-03-31 23:51:43 -04:00
|
|
|
|
2014-03-28 02:46:08 +00:00
|
|
|
global skip_if_not_v3
|
2018-10-30 23:04:19 +00:00
|
|
|
if not skip_if_not_v3:
|
|
|
|
skip_if_not_v3 = (swift_test_auth_version != '3'
|
|
|
|
or not all([not skip,
|
|
|
|
swift_test_user[3],
|
|
|
|
swift_test_key[3]]))
|
|
|
|
if not skip and skip_if_not_v3:
|
|
|
|
print('SKIPPING FUNCTIONAL TESTS SPECIFIC TO AUTH VERSION 3',
|
|
|
|
file=sys.stderr)
|
2014-03-28 02:46:08 +00:00
|
|
|
|
2014-11-25 14:42:42 +00:00
|
|
|
global skip_service_tokens
|
2018-10-30 23:04:19 +00:00
|
|
|
if not skip_service_tokens:
|
|
|
|
skip_service_tokens = not all([not skip, swift_test_user[4],
|
|
|
|
swift_test_key[4], swift_test_tenant[4],
|
|
|
|
swift_test_service_prefix])
|
|
|
|
if not skip and skip_service_tokens:
|
|
|
|
print(
|
|
|
|
'SKIPPING FUNCTIONAL TESTS SPECIFIC TO SERVICE TOKENS',
|
|
|
|
file=sys.stderr)
|
2014-11-25 14:42:42 +00:00
|
|
|
|
2015-03-25 13:19:36 +00:00
|
|
|
if policy_specified:
|
|
|
|
policies = FunctionalStoragePolicyCollection.from_info()
|
|
|
|
for p in policies:
|
|
|
|
# policy names are case-insensitive
|
|
|
|
if policy_specified.lower() == p['name'].lower():
|
|
|
|
_info('Using specified policy %s' % policy_specified)
|
|
|
|
FunctionalStoragePolicyCollection.policy_specified = p
|
|
|
|
Container.policy_specified = policy_specified
|
|
|
|
break
|
|
|
|
else:
|
|
|
|
_info(
|
|
|
|
'SKIPPING FUNCTIONAL TESTS: Failed to find specified policy %s'
|
|
|
|
% policy_specified)
|
|
|
|
raise Exception('Failed to find specified policy %s'
|
|
|
|
% policy_specified)
|
2015-07-16 09:35:37 +09:00
|
|
|
|
|
|
|
global skip_if_no_reseller_admin
|
2018-10-30 23:04:19 +00:00
|
|
|
if not skip_if_no_reseller_admin:
|
|
|
|
skip_if_no_reseller_admin = not all([not skip, swift_test_user[5],
|
|
|
|
swift_test_key[5],
|
|
|
|
swift_test_tenant[5]])
|
|
|
|
if not skip and skip_if_no_reseller_admin:
|
|
|
|
print('SKIPPING FUNCTIONAL TESTS DUE TO NO CONFIG FOR '
|
|
|
|
'RESELLER ADMIN', file=sys.stderr)
|
2015-07-16 09:35:37 +09:00
|
|
|
|
2014-04-10 15:37:15 -04:00
|
|
|
get_cluster_info()
|
|
|
|
|
2014-03-31 22:56:17 -04:00
|
|
|
|
|
|
|
def teardown_package():
|
|
|
|
global orig_collate
|
|
|
|
locale.setlocale(locale.LC_COLLATE, orig_collate)
|
2014-03-31 23:22:49 -04:00
|
|
|
|
2014-07-11 11:13:52 -04:00
|
|
|
# clean up containers and objects left behind after running tests
|
2015-08-07 18:14:13 -05:00
|
|
|
global config
|
2016-02-19 09:30:10 +00:00
|
|
|
|
|
|
|
if config:
|
2017-01-27 07:43:37 -08:00
|
|
|
try:
|
|
|
|
conn = Connection(config)
|
|
|
|
conn.authenticate()
|
|
|
|
account = Account(conn, config.get('account', config['username']))
|
|
|
|
account.delete_containers()
|
|
|
|
except (SkipTest):
|
|
|
|
pass
|
2014-07-11 11:13:52 -04:00
|
|
|
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
global in_process
|
2015-08-07 18:14:13 -05:00
|
|
|
global _test_socks
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
if in_process:
|
|
|
|
try:
|
2015-08-07 18:14:13 -05:00
|
|
|
for i, server in enumerate(_test_coros):
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
server.kill()
|
2015-08-07 18:14:13 -05:00
|
|
|
if not server.dead:
|
|
|
|
# kill it from the socket level
|
|
|
|
_test_socks[i].close()
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
except Exception:
|
|
|
|
pass
|
|
|
|
try:
|
|
|
|
rmtree(os.path.dirname(_testdir))
|
|
|
|
except Exception:
|
|
|
|
pass
|
2016-07-20 09:51:24 +00:00
|
|
|
|
2015-08-07 18:14:13 -05:00
|
|
|
reset_globals()
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
|
2014-03-31 23:22:49 -04:00
|
|
|
|
|
|
|
class AuthError(Exception):
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
|
|
class InternalServerError(Exception):
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
2014-11-25 14:42:42 +00:00
|
|
|
url = [None, None, None, None, None]
|
|
|
|
token = [None, None, None, None, None]
|
|
|
|
service_token = [None, None, None, None, None]
|
|
|
|
parsed = [None, None, None, None, None]
|
|
|
|
conn = [None, None, None, None, None]
|
2014-03-31 23:22:49 -04:00
|
|
|
|
|
|
|
|
2015-08-07 18:14:13 -05:00
|
|
|
def reset_globals():
|
|
|
|
global url, token, service_token, parsed, conn, config
|
|
|
|
url = [None, None, None, None, None]
|
|
|
|
token = [None, None, None, None, None]
|
|
|
|
service_token = [None, None, None, None, None]
|
|
|
|
parsed = [None, None, None, None, None]
|
|
|
|
conn = [None, None, None, None, None]
|
|
|
|
if config:
|
|
|
|
config = {}
|
|
|
|
|
|
|
|
|
2014-04-30 12:17:25 -06:00
|
|
|
def connection(url):
|
2023-09-25 15:51:42 -07:00
|
|
|
parsed_url, http_conn = http_connection(url, insecure=insecure)
|
2015-03-25 13:19:36 +00:00
|
|
|
|
|
|
|
orig_request = http_conn.request
|
|
|
|
|
|
|
|
# Add the policy header if policy_specified is set
|
|
|
|
def request_with_policy(method, url, body=None, headers={}):
|
|
|
|
version, account, container, obj = split_path(url, 1, 4, True)
|
|
|
|
if policy_specified and method == 'PUT' and container and not obj \
|
|
|
|
and 'X-Storage-Policy' not in headers:
|
|
|
|
headers['X-Storage-Policy'] = policy_specified
|
|
|
|
|
|
|
|
return orig_request(method, url, body, headers)
|
|
|
|
|
|
|
|
http_conn.request = request_with_policy
|
|
|
|
|
|
|
|
return parsed_url, http_conn
|
2014-04-30 12:17:25 -06:00
|
|
|
|
|
|
|
|
2014-11-25 14:42:42 +00:00
|
|
|
def get_url_token(user_index, os_options):
|
|
|
|
authargs = dict(snet=False,
|
|
|
|
tenant_name=swift_test_tenant[user_index],
|
|
|
|
auth_version=swift_test_auth_version,
|
|
|
|
os_options=os_options,
|
|
|
|
insecure=insecure)
|
2020-04-22 11:56:04 -07:00
|
|
|
url, token = get_auth(swift_test_auth,
|
|
|
|
swift_test_user[user_index],
|
|
|
|
swift_test_key[user_index],
|
|
|
|
**authargs)
|
|
|
|
if six.PY2 and not isinstance(url, bytes):
|
|
|
|
url = url.encode('utf-8')
|
|
|
|
if six.PY2 and not isinstance(token, bytes):
|
|
|
|
token = token.encode('utf-8')
|
|
|
|
return url, token
|
2014-11-25 14:42:42 +00:00
|
|
|
|
|
|
|
|
2014-03-31 23:22:49 -04:00
|
|
|
def retry(func, *args, **kwargs):
|
|
|
|
"""
|
|
|
|
You can use the kwargs to override:
|
|
|
|
'retries' (default: 5)
|
|
|
|
'use_account' (default: 1) - which user's token to pass
|
|
|
|
'url_account' (default: matches 'use_account') - which user's storage URL
|
|
|
|
'resource' (default: url[url_account] - URL to connect to; retry()
|
|
|
|
will interpolate the variable :storage_url: if present
|
2014-11-25 14:42:42 +00:00
|
|
|
'service_user' - add a service token from this user (1 indexed)
|
2014-03-31 23:22:49 -04:00
|
|
|
"""
|
2014-11-25 14:42:42 +00:00
|
|
|
global url, token, service_token, parsed, conn
|
2014-03-31 23:22:49 -04:00
|
|
|
retries = kwargs.get('retries', 5)
|
|
|
|
attempts, backoff = 0, 1
|
|
|
|
|
|
|
|
# use account #1 by default; turn user's 1-indexed account into 0-indexed
|
|
|
|
use_account = kwargs.pop('use_account', 1) - 1
|
2014-11-25 14:42:42 +00:00
|
|
|
service_user = kwargs.pop('service_user', None)
|
|
|
|
if service_user:
|
|
|
|
service_user -= 1 # 0-index
|
2014-03-31 23:22:49 -04:00
|
|
|
|
|
|
|
# access our own account by default
|
|
|
|
url_account = kwargs.pop('url_account', use_account + 1) - 1
|
2014-03-28 02:46:08 +00:00
|
|
|
os_options = {'user_domain_name': swift_test_domain[use_account],
|
|
|
|
'project_domain_name': swift_test_domain[use_account]}
|
2014-03-31 23:22:49 -04:00
|
|
|
while attempts <= retries:
|
2015-02-26 12:30:30 -08:00
|
|
|
auth_failure = False
|
2014-03-31 23:22:49 -04:00
|
|
|
attempts += 1
|
|
|
|
try:
|
|
|
|
if not url[use_account] or not token[use_account]:
|
2014-11-25 14:42:42 +00:00
|
|
|
url[use_account], token[use_account] = get_url_token(
|
|
|
|
use_account, os_options)
|
2014-03-31 23:22:49 -04:00
|
|
|
parsed[use_account] = conn[use_account] = None
|
|
|
|
if not parsed[use_account] or not conn[use_account]:
|
|
|
|
parsed[use_account], conn[use_account] = \
|
2014-04-30 12:17:25 -06:00
|
|
|
connection(url[use_account])
|
2014-03-31 23:22:49 -04:00
|
|
|
|
|
|
|
# default resource is the account url[url_account]
|
|
|
|
resource = kwargs.pop('resource', '%(storage_url)s')
|
|
|
|
template_vars = {'storage_url': url[url_account]}
|
|
|
|
parsed_result = urlparse(resource % template_vars)
|
2014-11-25 14:42:42 +00:00
|
|
|
if isinstance(service_user, int):
|
|
|
|
if not service_token[service_user]:
|
|
|
|
dummy, service_token[service_user] = get_url_token(
|
|
|
|
service_user, os_options)
|
|
|
|
kwargs['service_token'] = service_token[service_user]
|
2014-03-31 23:22:49 -04:00
|
|
|
return func(url[url_account], token[use_account],
|
|
|
|
parsed_result, conn[url_account],
|
|
|
|
*args, **kwargs)
|
|
|
|
except (socket.error, HTTPException):
|
|
|
|
if attempts > retries:
|
|
|
|
raise
|
|
|
|
parsed[use_account] = conn[use_account] = None
|
2014-11-25 14:42:42 +00:00
|
|
|
if service_user:
|
|
|
|
service_token[service_user] = None
|
2014-03-31 23:22:49 -04:00
|
|
|
except AuthError:
|
2015-02-26 12:30:30 -08:00
|
|
|
auth_failure = True
|
2014-03-31 23:22:49 -04:00
|
|
|
url[use_account] = token[use_account] = None
|
2014-11-25 14:42:42 +00:00
|
|
|
if service_user:
|
|
|
|
service_token[service_user] = None
|
2014-03-31 23:22:49 -04:00
|
|
|
except InternalServerError:
|
|
|
|
pass
|
|
|
|
if attempts <= retries:
|
2015-02-26 12:30:30 -08:00
|
|
|
if not auth_failure:
|
|
|
|
sleep(backoff)
|
2014-03-31 23:22:49 -04:00
|
|
|
backoff *= 2
|
|
|
|
raise Exception('No result after %s retries.' % retries)
|
|
|
|
|
|
|
|
|
|
|
|
def check_response(conn):
|
|
|
|
resp = conn.getresponse()
|
|
|
|
if resp.status == 401:
|
|
|
|
resp.read()
|
|
|
|
raise AuthError()
|
|
|
|
elif resp.status // 100 == 5:
|
|
|
|
resp.read()
|
|
|
|
raise InternalServerError()
|
|
|
|
return resp
|
|
|
|
|
|
|
|
|
|
|
|
def load_constraint(name):
|
2014-04-10 15:37:15 -04:00
|
|
|
global cluster_info
|
|
|
|
try:
|
|
|
|
c = cluster_info['swift'][name]
|
|
|
|
except KeyError:
|
|
|
|
raise SkipTest("Missing constraint: %s" % name)
|
2014-03-31 23:22:49 -04:00
|
|
|
if not isinstance(c, int):
|
2014-04-10 15:37:15 -04:00
|
|
|
raise SkipTest("Bad value, %r, for constraint: %s" % (c, name))
|
2014-03-31 23:22:49 -04:00
|
|
|
return c
|
|
|
|
|
|
|
|
|
2014-04-09 19:15:04 +08:00
|
|
|
def get_storage_policy_from_cluster_info(info):
|
|
|
|
policies = info['swift'].get('policies', {})
|
|
|
|
default_policy = []
|
|
|
|
non_default_policies = []
|
|
|
|
for p in policies:
|
|
|
|
if p.get('default', {}):
|
|
|
|
default_policy.append(p)
|
|
|
|
else:
|
|
|
|
non_default_policies.append(p)
|
|
|
|
return default_policy, non_default_policies
|
|
|
|
|
|
|
|
|
2014-03-31 23:22:49 -04:00
|
|
|
def reset_acl():
|
|
|
|
def post(url, token, parsed, conn):
|
|
|
|
conn.request('POST', parsed.path, '', {
|
|
|
|
'X-Auth-Token': token,
|
|
|
|
'X-Account-Access-Control': '{}'
|
|
|
|
})
|
|
|
|
return check_response(conn)
|
|
|
|
resp = retry(post, use_account=1)
|
|
|
|
resp.read()
|
|
|
|
|
|
|
|
|
|
|
|
def requires_acls(f):
|
|
|
|
@functools.wraps(f)
|
|
|
|
def wrapper(*args, **kwargs):
|
In-process swift server for functional tests
Provide a way to run the functional tests using a p/a/c/o server setup
in the same process running the nosetests infrastructure.
By setting the environment variable, SWIFT_TEST_IN_PROCESS, to a true
value, the functional test framework will construct a set of proxy,
account, container and object servers running in the same process that
is running the functional tests, ignoring any external swift
service. This in-process swift environment is akin to the one used in
test/unit/proxy/test_server.py.
Setting that same environment variable to a false value will ensure the
in-process servers are not used.
When the above environment variable is not present, and the
/etc/swift/test.conf is _not_ present (or present but empty) on the
system where the functional tests are executing, the in-process
environment will be used. Previously, if no /etc/swift/test.conf file
was found, the tests would just be marked as skipped.
Using this in-process method allows one to gather code coverage using
the functional tests to exercise code paths, in addition to the unit
tests, or more easily debug existing functional tests, or even write new
ones.
There are two constraints that are changed for use with the in-process
functional tests: max_file_size is lowered to roughly 8 MB, and
client_timeout is set to 4s.
Change-Id: I5acd65e3068868d6509feae1d1954237d37fad45
2014-01-11 00:18:04 -05:00
|
|
|
global skip, cluster_info
|
2014-04-10 15:37:15 -04:00
|
|
|
if skip or not cluster_info:
|
2015-02-03 18:24:41 +00:00
|
|
|
raise SkipTest('Requires account ACLs')
|
2014-03-31 23:22:49 -04:00
|
|
|
# Determine whether this cluster has account ACLs; if not, skip test
|
|
|
|
if not cluster_info.get('tempauth', {}).get('account_acls'):
|
2015-02-03 18:24:41 +00:00
|
|
|
raise SkipTest('Requires account ACLs')
|
|
|
|
if swift_test_auth_version != '1':
|
2014-03-31 23:22:49 -04:00
|
|
|
# remove when keystoneauth supports account acls
|
2015-02-03 18:24:41 +00:00
|
|
|
raise SkipTest('Requires account ACLs')
|
2014-03-31 23:22:49 -04:00
|
|
|
reset_acl()
|
|
|
|
try:
|
|
|
|
rv = f(*args, **kwargs)
|
|
|
|
finally:
|
|
|
|
reset_acl()
|
|
|
|
return rv
|
|
|
|
return wrapper
|
2014-04-09 19:15:04 +08:00
|
|
|
|
|
|
|
|
|
|
|
class FunctionalStoragePolicyCollection(object):
|
|
|
|
|
2015-03-25 13:19:36 +00:00
|
|
|
# policy_specified is set in __init__.py when tests are being set up.
|
|
|
|
policy_specified = None
|
|
|
|
|
2014-04-09 19:15:04 +08:00
|
|
|
def __init__(self, policies):
|
|
|
|
self._all = policies
|
|
|
|
self.default = None
|
|
|
|
for p in self:
|
|
|
|
if p.get('default', False):
|
|
|
|
assert self.default is None, 'Found multiple default ' \
|
|
|
|
'policies %r and %r' % (self.default, p)
|
|
|
|
self.default = p
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
def from_info(cls, info=None):
|
|
|
|
if not (info or cluster_info):
|
|
|
|
get_cluster_info()
|
|
|
|
info = info or cluster_info
|
|
|
|
try:
|
|
|
|
policy_info = info['swift']['policies']
|
|
|
|
except KeyError:
|
|
|
|
raise AssertionError('Did not find any policy info in %r' % info)
|
|
|
|
policies = cls(policy_info)
|
|
|
|
assert policies.default, \
|
|
|
|
'Did not find default policy in %r' % policy_info
|
|
|
|
return policies
|
|
|
|
|
|
|
|
def __len__(self):
|
|
|
|
return len(self._all)
|
|
|
|
|
|
|
|
def __iter__(self):
|
|
|
|
return iter(self._all)
|
|
|
|
|
|
|
|
def __getitem__(self, index):
|
|
|
|
return self._all[index]
|
|
|
|
|
|
|
|
def filter(self, **kwargs):
|
|
|
|
return self.__class__([p for p in self if all(
|
|
|
|
p.get(k) == v for k, v in kwargs.items())])
|
|
|
|
|
|
|
|
def exclude(self, **kwargs):
|
|
|
|
return self.__class__([p for p in self if all(
|
|
|
|
p.get(k) != v for k, v in kwargs.items())])
|
|
|
|
|
|
|
|
def select(self):
|
2015-03-25 13:19:36 +00:00
|
|
|
# check that a policy was specified and that it is available
|
|
|
|
# in the current list (i.e., hasn't been excluded of the current list)
|
|
|
|
if self.policy_specified and self.policy_specified in self:
|
|
|
|
return self.policy_specified
|
|
|
|
else:
|
|
|
|
return random.choice(self)
|
2014-04-09 19:15:04 +08:00
|
|
|
|
|
|
|
|
|
|
|
def requires_policies(f):
|
|
|
|
@functools.wraps(f)
|
|
|
|
def wrapper(self, *args, **kwargs):
|
|
|
|
if skip:
|
|
|
|
raise SkipTest
|
|
|
|
try:
|
|
|
|
self.policies = FunctionalStoragePolicyCollection.from_info()
|
|
|
|
except AssertionError:
|
|
|
|
raise SkipTest("Unable to determine available policies")
|
|
|
|
if len(self.policies) < 2:
|
|
|
|
raise SkipTest("Multiple policies not enabled")
|
|
|
|
return f(self, *args, **kwargs)
|
|
|
|
|
|
|
|
return wrapper
|
2019-03-15 15:18:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
def requires_bulk(f):
|
|
|
|
@functools.wraps(f)
|
|
|
|
def wrapper(*args, **kwargs):
|
|
|
|
if skip or not cluster_info:
|
|
|
|
raise SkipTest('Requires bulk middleware')
|
|
|
|
# Determine whether this cluster has bulk middleware; if not, skip test
|
|
|
|
if not cluster_info.get('bulk_upload', {}):
|
|
|
|
raise SkipTest('Requires bulk middleware')
|
|
|
|
return f(*args, **kwargs)
|
|
|
|
return wrapper
|