Automate functional tests

By storing the functional tests configuration files in the
repo, we can now run the functional_tests.sh to setup,
run the functional tests, and teardown.

Most likely this will be able to be run as a user from
the same directory as the repo, but at the moment, the
configuration files are copied to /etc/swift.

The only requirements are:
1. /etc/swift does not exist.  That way the tests will
not interfere with an existing deployment.
2. /mnt/gluster-object/test and /mnt/gluster-object/test2
must have been created and setup correctly on an XFS
or GlusterFS volume
3. sudo rights without password prompt
4. glusterfs-openstack-swift-* rpm must not be installed
on the system

Once the requirements are met, you can execute the tests
as follows:

$ bash tools/functional_tests.sh

Change-Id: Icdbcd420355b02e64f294df7298a3e473b343655
Signed-off-by: Luis Pabon <lpabon@redhat.com>
Reviewed-on: http://review.gluster.org/5281
Reviewed-by: Peter Portante <pportant@redhat.com>

1 files changed, 61 insertions, 0 deletions

diff --git a/test/functional/conf/proxy-server.conf b/test/functional/conf/proxy-server.conf
new file mode 100644
index 0000000..ded2659
--- /dev/null
+++ b/test/functional/conf/proxy-server.conf
@@ -0,0 +1,61 @@
+[DEFAULT]
+bind_port = 8080
+user = root
+log_facility = LOG_LOCAL1
+# Consider using 1 worker per CPU
+workers = 1
+
+[pipeline:main]
+pipeline = healthcheck cache tempauth proxy-server
+
+[app:proxy-server]
+use = egg:gluster_swift#proxy
+log_facility = LOG_LOCAL1
+# The API allows for account creation and deletion, but since Gluster/Swift
+# automounts a Gluster volume for a given account, there is no way to create
+# or delete an account. So leave this off.
+allow_account_management = false
+account_autocreate = true
+# Only need to recheck the account exists once a day
+recheck_account_existence = 86400
+# May want to consider bumping this up if containers are created and destroyed
+# infrequently.
+recheck_container_existence = 60
+# Timeout clients that don't read or write to the proxy server after 5
+# seconds.
+client_timeout = 5
+# Give more time to connect to the object, container or account servers in
+# cases of high load.
+conn_timeout = 5
+# For high load situations, once connected to an object, container or account
+# server, allow for delays communicating with them.
+node_timeout = 60
+# May want to consider bumping up this value to 1 - 4 MB depending on how much
+# traffic is for multi-megabyte or gigabyte requests; perhaps matching the
+# stripe width (not stripe element size) of your storage volume is a good
+# starting point. See below for sizing information.
+object_chunk_size = 65536
+# If you do decide to increase the object_chunk_size, then consider lowering
+# this value to one. Up to "put_queue_length" object_chunk_size'd buffers can
+# be queued to the object server for processing. Given one proxy server worker
+# can handle up to 1,024 connections, by default, it will consume 10 * 65,536
+# * 1,024 bytes of memory in the worse case (default values). Be sure the
+# amount of memory available on the system can accommodate increased values
+# for object_chunk_size.
+put_queue_depth = 10
+
+[filter:healthcheck]
+use = egg:swift#healthcheck
+
+[filter:tempauth]
+use = egg:swift#tempauth
+user_admin_admin = admin .admin .reseller_admin
+user_test_tester = testing .admin
+user_test2_tester2 = testing2 .admin
+user_test_tester3 = testing3
+
+[filter:cache]
+use = egg:swift#memcache
+# Update this line to contain a comma separated list of memcache servers
+# shared by all nodes running the proxy-server service.
+memcache_servers = localhost:11211