Compatibility tests for S3 clones
Find a file
hechuang 2d7d79c95d rgw: Data encryption is not follow the AWS agreement
Encryption request headers should not be sent for GET requests and HEAD
requests if your object uses SSE-KMS/SSE-S3 or you’ll get an HTTP 400
BadRequest error.

Signed-off-by: hechuang <hechuang@xsky.com>
(cherry picked from commit 58944d0ba6)
2017-08-30 08:56:55 -04:00
s3tests rgw: Data encryption is not follow the AWS agreement 2017-08-30 08:56:55 -04:00
.gitignore Say ".yaml" not ".yml". This is not MS-DOS, and YML is a Yahoo XML dialect. 2011-07-26 14:20:28 -07:00
bootstrap remove python2 pip 2017-02-02 16:33:42 -08:00
config.yaml.SAMPLE Added micro instuction how to configure tests for KMS (barbican) integration 2017-03-28 10:03:59 -04:00
LICENSE MIT licensed. 2011-04-04 15:19:59 -07:00
README.rst Added micro instuction how to configure tests for KMS (barbican) integration 2017-03-28 10:03:59 -04:00
request_decision_graph.yml fuzz: Write fuzzer rules for WebsiteConfiguration. 2015-06-14 22:11:42 -07:00
requirements.txt website: refactor and add redirect testcases, so far 3 failures out of 27 new tests. 2016-04-20 16:08:57 -07:00
setup.py gevent: bump to >=1.0 2016-04-11 16:01:34 +08:00
siege.conf dho-qa: Add siege config file and document running siege 2011-07-08 11:27:56 -07:00

========================
 S3 compatibility tests
========================

This is a set of completely unofficial Amazon AWS S3 compatibility
tests, that will hopefully be useful to people implementing software
that exposes an S3-like API.

The tests only cover the REST interface.

The tests use the Boto library, so any e.g. HTTP-level differences
that Boto papers over, the tests will not be able to discover. Raw
HTTP tests may be added later.

The tests use the Nose test framework. To get started, ensure you have
the ``virtualenv`` software installed; e.g. on Debian/Ubuntu::

	sudo apt-get install python-virtualenv

and then run::

	./bootstrap

You will need to create a configuration file with the location of the
service and two different credentials, something like this::

	[DEFAULT]
	## this section is just used as default for all the "s3 *"
        ## sections, you can place these variables also directly there

	## replace with e.g. "localhost" to run against local software
	host = s3.amazonaws.com

	## uncomment the port to use something other than 80
	# port = 8080

	## say "no" to disable TLS
	is_secure = yes

	[fixtures]
	## all the buckets created will start with this prefix;
	## {random} will be filled with random characters to pad
	## the prefix to 30 characters long, and avoid collisions
	bucket prefix = YOURNAMEHERE-{random}-

	[s3 main]
	## the tests assume two accounts are defined, "main" and "alt".

	## user_id is a 64-character hexstring
	user_id = 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

	## display name typically looks more like a unix login, "jdoe" etc
	display_name = youruseridhere

	## replace these with your access keys
	access_key = ABCDEFGHIJKLMNOPQRST
	secret_key = abcdefghijklmnopqrstuvwxyzabcdefghijklmn

	## replace with key id obtained when secret is created, or delete if KMS not tested
	kms_keyid = 01234567-89ab-cdef-0123-456789abcdef

	[s3 alt]
	## another user account, used for ACL-related tests
	user_id = 56789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01234
	display_name = john.doe
	## the "alt" user needs to have email set, too
	email = john.doe@example.com
	access_key = NOPQRSTUVWXYZABCDEFG
	secret_key = nopqrstuvwxyzabcdefghijklmnabcdefghijklm

Once you have that, you can run the tests with::

	S3TEST_CONF=your.conf ./virtualenv/bin/nosetests

To gather a list of tests being run, use the flags::

	 -v --collect-only

You can specify what test(s) to run::

	S3TEST_CONF=your.conf ./virtualenv/bin/nosetests s3tests.functional.test_s3:test_bucket_list_empty

Some tests have attributes set based on their current reliability and
things like AWS not enforcing their spec stricly. You can filter tests
based on their attributes::

	S3TEST_CONF=aws.conf ./virtualenv/bin/nosetests -a '!fails_on_aws'


TODO
====

- We should assume read-after-write consistency, and make the tests
  actually request such a location.
  http://aws.amazon.com/s3/faqs/#What_data_consistency_model_does_Amazon_S3_employ

- Test direct HTTP downloads, like a web browser would do.