object-storage: final changes to remove swift diff

Final set of changes to remove the diffs carried to make UFO work with
OpenStack Swift. The code is now a complete layering on top of OpenStack Swift
where we either "monkey patch" or subclass as necessary.

See BZ 870589 (https://bugzilla.redhat.com/show_bug.cgi?id=870589).

There are a lot of changes here due for the most part to rearranging the
directory hierarchy to have create a proper python module hierarchy under the
"gluster" namespace. Plugin references have been removed. The differences that
used to be in the swift.diff file are now replaced with server implementations
for account, container, object, and proxy that subclass the swift versions.

Additionally, the plugins/conf directory has been moved to the "etc"
directory, and the plugins/bin directory promoted a level.

Unit tests pass.

A new setup.py file is provided so that the install process can use it for
creating all the necessary python install infrastructure (eggs and paste
support).

A new RPM spec file is provided which to properly install the new code, and
the sample configuration files have been modified to reference the new python
egg.

Change-Id: I4316c1b66dca80f847fe9b0d583174689c175599
BUG: 870589
Signed-off-by: Peter Portante <peter.portante@redhat.com>
Reviewed-on: http://review.gluster.org/4180
Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com>
Reviewed-by: Mohammed Junaid <junaid@redhat.com>
Tested-by: Kaleb KEITHLEY <kkeithle@redhat.com>

6 files changed, 196 insertions, 0 deletions

diff --git a/swift/1.4.8/etc/account-server/1.conf-gluster b/swift/1.4.8/etc/account-server/1.conf-gluster
new file mode 100644
index 000000000..da8f31726
--- /dev/null
+++ b/swift/1.4.8/etc/account-server/1.conf-gluster
@@ -0,0 +1,19 @@
+[DEFAULT]
+devices = /mnt/gluster-object
+mount_check = true
+bind_port = 6012
+user = root
+log_facility = LOG_LOCAL2
+
+[pipeline:main]
+pipeline = account-server
+
+[app:account-server]
+use = egg:gluster_swift_ufo#account
+
+[account-replicator]
+vm_test_mode = yes
+
+[account-auditor]
+
+[account-reaper]
diff --git a/swift/1.4.8/etc/container-server/1.conf-gluster b/swift/1.4.8/etc/container-server/1.conf-gluster
new file mode 100644
index 000000000..acad62135
--- /dev/null
+++ b/swift/1.4.8/etc/container-server/1.conf-gluster
@@ -0,0 +1,21 @@
+[DEFAULT]
+devices = /mnt/gluster-object
+mount_check = true
+bind_port = 6011
+user = root
+log_facility = LOG_LOCAL2
+
+[pipeline:main]
+pipeline = container-server
+
+[app:container-server]
+use = egg:gluster_swift_ufo#container
+
+[container-replicator]
+vm_test_mode = yes
+
+[container-updater]
+
+[container-auditor]
+
+[container-sync]
diff --git a/swift/1.4.8/etc/fs.conf-gluster b/swift/1.4.8/etc/fs.conf-gluster
new file mode 100644
index 000000000..bbbdc2bd1
--- /dev/null
+++ b/swift/1.4.8/etc/fs.conf-gluster
@@ -0,0 +1,13 @@
+[DEFAULT]
+# IP address of a GlusterFS volume server member. By default, we assume the
+# local host.
+mount_ip = localhost
+
+# The GlusterFS server need not be local, a remote server can also be used
+# by setting "remote_cluster = yes".
+remote_cluster = no
+
+# By default it is assumed the Gluster volumes can be accessed using other
+# methods besides UFO (not object only), which disables a caching
+# optimizations in order to keep in sync with file system changes.
+object_only = no
diff --git a/swift/1.4.8/etc/object-server/1.conf-gluster b/swift/1.4.8/etc/object-server/1.conf-gluster
new file mode 100644
index 000000000..fe157a9b5
--- /dev/null
+++ b/swift/1.4.8/etc/object-server/1.conf-gluster
@@ -0,0 +1,19 @@
+[DEFAULT]
+devices = /mnt/gluster-object
+mount_check = true
+bind_port = 6010
+user = root
+log_facility = LOG_LOCAL2
+
+[pipeline:main]
+pipeline = object-server
+
+[app:object-server]
+use = egg:gluster_swift_ufo#object
+
+[object-replicator]
+vm_test_mode = yes
+
+[object-updater]
+
+[object-auditor]
diff --git a/swift/1.4.8/etc/proxy-server.conf-gluster b/swift/1.4.8/etc/proxy-server.conf-gluster
new file mode 100644
index 000000000..30eb745bf
--- /dev/null
+++ b/swift/1.4.8/etc/proxy-server.conf-gluster
@@ -0,0 +1,33 @@
+[DEFAULT]
+bind_port = 8080
+user = root
+log_facility = LOG_LOCAL1
+
+[pipeline:main]
+pipeline = healthcheck cache tempauth proxy-server
+
+[app:proxy-server]
+use = egg:gluster_swift_ufo#proxy
+allow_account_management = true
+account_autocreate = true
+
+[filter:tempauth]
+use = egg:swift#tempauth
+# Here you need to add users explicitly. See the OpenStack Swift Deployment
+# Guide for more information. The user and user64 directives take the
+# following form:
+#     user_<account>_<username> = <key> [group] [group] [...] [storage_url]
+#     user64_<account_b64>_<username_b64> = <key> [group] [group] [...] [storage_url]
+# Where you use user64 for accounts and/or usernames that include underscores.
+#
+# NOTE (and WARNING): The account name must match the device name specified
+# when generating the account, container, and object build rings.
+#
+# E.g.
+#     user_ufo0_admin = abc123 .admin
+
+[filter:healthcheck]
+use = egg:swift#healthcheck
+
+[filter:cache]
+use = egg:swift#memcache
diff --git a/swift/1.4.8/etc/swift.conf-gluster b/swift/1.4.8/etc/swift.conf-gluster
new file mode 100644
index 000000000..25c3ca157
--- /dev/null
+++ b/swift/1.4.8/etc/swift.conf-gluster
@@ -0,0 +1,91 @@
+[DEFAULT]
+
+
+[swift-hash]
+# random unique string that can never change (DO NOT LOSE)
+swift_hash_path_suffix = gluster
+
+
+# The swift-constraints section sets the basic constraints on data
+# saved in the swift cluster.
+
+[swift-constraints]
+
+# max_file_size is the largest "normal" object that can be saved in
+# the cluster. This is also the limit on the size of each segment of
+# a "large" object when using the large object manifest support.
+# This value is set in bytes. Setting it to lower than 1MiB will cause
+# some tests to fail. It is STRONGLY recommended to leave this value at
+# the default (5 * 2**30 + 2).
+
+# FIXME: Really? Gluster can handle a 2^64 sized file? And can the fronting
+# web service handle such a size? I think with UFO, we need to keep with the
+# default size from Swift and encourage users to research what size their web
+# services infrastructure can handle.
+
+max_file_size = 18446744073709551616
+
+
+# max_meta_name_length is the max number of bytes in the utf8 encoding
+# of the name portion of a metadata header.
+
+#max_meta_name_length = 128
+
+
+# max_meta_value_length is the max number of bytes in the utf8 encoding
+# of a metadata value
+
+#max_meta_value_length = 256
+
+
+# max_meta_count is the max number of metadata keys that can be stored
+# on a single account, container, or object
+
+#max_meta_count = 90
+
+
+# max_meta_overall_size is the max number of bytes in the utf8 encoding
+# of the metadata (keys + values)
+
+#max_meta_overall_size = 4096
+
+
+# max_object_name_length is the max number of bytes in the utf8 encoding of an
+# object name: Gluster FS can handle much longer file names, but the length
+# between the slashes of the URL is handled below. Remember that most web
+# clients can't handle anything greater than 2048, and those that do are
+# rather clumsy.
+
+max_object_name_length = 2048
+
+# max_object_name_component_length (GlusterFS) is the max number of bytes in
+# the utf8 encoding of an object name component (the part between the
+# slashes); this is a limit imposed by the underlying file system (for XFS it
+# is 255 bytes).
+
+max_object_name_component_length = 255
+
+# container_listing_limit is the default (and max) number of items
+# returned for a container listing request
+
+#container_listing_limit = 10000
+
+
+# account_listing_limit is the default (and max) number of items returned
+# for an account listing request
+
+#account_listing_limit = 10000
+
+
+# max_account_name_length is the max number of bytes in the utf8 encoding of
+# an account name: Gluster FS Filename limit (XFS limit?), must be the same
+# size as max_object_name_component_length above.
+
+max_account_name_length = 255
+
+
+# max_container_name_length is the max number of bytes in the utf8 encoding
+# of a container name: Gluster FS Filename limit (XFS limit?), must be the same
+# size as max_object_name_component_length above.
+
+max_container_name_length = 255