Merge from trunk

CHANGELOG

@@ -1,3 +1,19 @@
+swift (1.4.1)
+
+    * st renamed to swift
+
+    * swauth was separated froms swift. It is now its own project and can be
+      found at https://github.com/gholt/swauth.
+
+    * tempauth middleware added as an extremely limited auth system for dev
+      work.
+
+    * Account and container listings now properly labeled UTF-8 (previously the
+      label was "utf8").
+
+    * Accounts are auto-created if an auth token is valid when the
+      account_autocreate proxy config parameter is set to true.
+
 swift (1.4.0)
 
     * swift-bench now cleans up containers it creates.

doc/source/development_saio.rst

@@ -633,7 +633,7 @@ Setting up scripts for running Swift
   #. `recreateaccounts`
   #. Get an `X-Storage-Url` and `X-Auth-Token`: ``curl -v -H 'X-Storage-User: test:tester' -H 'X-Storage-Pass: testing' http://127.0.0.1:8080/auth/v1.0``
   #. Check that you can GET account: ``curl -v -H 'X-Auth-Token: <token-from-x-auth-token-above>' <url-from-x-storage-url-above>``
-  #. Check that `st` works: `st -A http://127.0.0.1:8080/auth/v1.0 -U test:tester -K testing stat`
+  #. Check that `swift` works: `swift -A http://127.0.0.1:8080/auth/v1.0 -U test:tester -K testing stat`
   #. `cp ~/swift/trunk/test/functional/sample.conf /etc/swift/func_test.conf`
   #. `cd ~/swift/trunk; ./.functests` (Note: functional tests will first delete
      everything in the configured accounts.)

doc/source/howto_installmultinode.rst

@@ -372,34 +372,34 @@ You run these commands from the Proxy node.
 
         curl -k -v -H 'X-Auth-Token: <token-from-x-auth-token-above>' <url-from-x-storage-url-above>
 
-#. Check that ``st`` works  (at this point, expect zero containers, zero objects, and zero bytes)::
+#. Check that ``swift`` works  (at this point, expect zero containers, zero objects, and zero bytes)::
 
-        st -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass stat
+        swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass stat
 
-#. Use ``st`` to upload a few files named 'bigfile[1-2].tgz' to a container named 'myfiles'::
+#. Use ``swift`` to upload a few files named 'bigfile[1-2].tgz' to a container named 'myfiles'::
 
-        st -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass upload myfiles bigfile1.tgz
-        st -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass upload myfiles bigfile2.tgz
+        swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass upload myfiles bigfile1.tgz
+        swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass upload myfiles bigfile2.tgz
 
-#. Use ``st`` to download all files from the 'myfiles' container::
+#. Use ``swift`` to download all files from the 'myfiles' container::
 
-        st -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass download myfiles
+        swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass download myfiles
 
-#. Use ``st`` to save a backup of your builder files to a container named 'builders'. Very important not to lose your builders!::
+#. Use ``swift`` to save a backup of your builder files to a container named 'builders'. Very important not to lose your builders!::
 
-        st -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass upload builders /etc/swift/*.builder
+        swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass upload builders /etc/swift/*.builder
 
-#. Use ``st`` to list your containers::
+#. Use ``swift`` to list your containers::
 
-        st -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass list
+        swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass list
 
-#. Use ``st`` to list the contents of your 'builders' container::
+#. Use ``swift`` to list the contents of your 'builders' container::
 
-        st -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass list builders
+        swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass list builders
 
-#. Use ``st`` to download all files from the 'builders' container::
+#. Use ``swift`` to download all files from the 'builders' container::
 
-        st -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass download builders
+        swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass download builders
 
 .. _add-proxy-server:
 

doc/source/overview_large_objects.rst

@@ -14,24 +14,24 @@ concatenated as a single object. This also offers much greater upload speed
 with the possibility of parallel uploads of the segments.
 
 ----------------------------------
-Using ``st`` for Segmented Objects
+Using ``swift`` for Segmented Objects
 ----------------------------------
 
-The quickest way to try out this feature is use the included ``st`` Swift Tool.
+The quickest way to try out this feature is use the included ``swift`` Swift Tool.
 You can use the ``-S`` option to specify the segment size to use when splitting
 a large file. For example::
 
-    st upload test_container -S 1073741824 large_file
+    swift upload test_container -S 1073741824 large_file
 
 This would split the large_file into 1G segments and begin uploading those
-segments in parallel. Once all the segments have been uploaded, ``st`` will
+segments in parallel. Once all the segments have been uploaded, ``swift`` will
 then create the manifest file so the segments can be downloaded as one.
 
-So now, the following ``st`` command would download the entire large object::
+So now, the following ``swift`` command would download the entire large object::
 
-    st download test_container large_file
+    swift download test_container large_file
 
-``st`` uses a strict convention for its segmented object support. In the above
+``swift`` uses a strict convention for its segmented object support. In the above
 example it will upload all the segments into a second container named
 test_container_segments. These segments will have names like
 large_file/1290206778.25/21474836480/00000000,
@@ -43,7 +43,7 @@ the segment name format of <name>/<timestamp>/<size>/<segment> is so that an
 upload of a new file with the same name won't overwrite the contents of the
 first until the last moment when the manifest file is updated.
 
-``st`` will manage these segment files for you, deleting old segments on
+``swift`` will manage these segment files for you, deleting old segments on
 deletes and overwrites, etc. You can override this behavior with the
 ``--leave-segments`` option if desired; this is useful if you want to have
 multiple versions of the same large object available.
@@ -53,14 +53,14 @@ Direct API
 ----------
 
 You can also work with the segments and manifests directly with HTTP requests
-instead of having ``st`` do that for you. You can just upload the segments like
+instead of having ``swift`` do that for you. You can just upload the segments like
 you would any other object and the manifest is just a zero-byte file with an
 extra ``X-Object-Manifest`` header.
 
 All the object segments need to be in the same container, have a common object
 name prefix, and their names sort in the order they should be concatenated.
 They don't have to be in the same container as the manifest file will be, which
-is useful to keep container listings clean as explained above with ``st``.
+is useful to keep container listings clean as explained above with ``swift``.
 
 The manifest file is simply a zero-byte file with the extra
 ``X-Object-Manifest: <container>/<prefix>`` header, where ``<container>`` is

setup.py

@@ -76,7 +76,7 @@ setup(
         ],
     install_requires=[],  # removed for better compat
     scripts=[
-        'bin/st', 'bin/swift-account-auditor',
+        'bin/swift', 'bin/swift-account-auditor',
         'bin/swift-account-audit', 'bin/swift-account-reaper',
         'bin/swift-account-replicator', 'bin/swift-account-server',
         'bin/swift-container-auditor',

swift/__init__.py

@@ -14,7 +14,7 @@ class Version(object):
             return '%s-dev' % (self.canonical_version,)
 
 
-_version = Version('1.4.1', False)
+_version = Version('1.4.2', False)
 __version__ = _version.pretty_version
 __canonical_version__ = _version.canonical_version
 

swift/common/middleware/staticweb.py

@@ -74,36 +74,36 @@ the .../listing.css style sheet. If you "view source" in your browser on a
 listing page, you will see the well defined document structure that can be
 styled.
 
-Example usage of this middleware via ``st``:
+Example usage of this middleware via ``swift``:
 
     Make the container publicly readable::
 
-        st post -r '.r:*' container
+        swift post -r '.r:*' container
 
     You should be able to get objects directly, but no index.html resolution or
     listings.
 
     Set an index file directive::
 
-        st post -m 'web-index:index.html' container
+        swift post -m 'web-index:index.html' container
 
     You should be able to hit paths that have an index.html without needing to
     type the index.html part.
 
     Turn on listings::
 
-        st post -m 'web-listings: true' container
+        swift post -m 'web-listings: true' container
 
     Now you should see object listings for paths and pseudo paths that have no
     index.html.
 
     Enable a custom listings style sheet::
 
-        st post -m 'web-listings-css:listings.css' container
+        swift post -m 'web-listings-css:listings.css' container
 
     Set an error file::
 
-        st post -m 'web-error:error.html' container
+        swift post -m 'web-error:error.html' container
 
     Now 401's should load 401error.html, 404's should load 404error.html, etc.
 """