...and pin us to stable/newton. (I wanted stable/mitaka so it'd match
Keystone, but apparently then pbr is too old for Keystone to install
a keystone-wsgi-admin script.)
This prevents various version conflicts; the most recent was from
oslo.service blocking too-new eventlet.
Change-Id: I115dc231a9156a5bceacaa21d6242bb934fbbd24
Related-Change: I3b2196fdef9936f1c7d468f9c7c9b9246d3d26fd
Related-Change: I6cbbfd7260571f42ea65c6622aa6b410a0e43b28
Sphinx wants babel!=2.0,>=1.3 which drags in 2.4.0, but oslo.i18n
(required by keystone) wants Babel!=2.4.0,>=2.3.4 leading to an
error when starting keystone.
Also, bump up the sleep before verifying that keystone is running
-- at just one second, keystone hadn't had a chance to raise the
ContextualVersionConflict yet. Further, verify that curl can actually
reach keystone on the expected port.
Change-Id: I6cbbfd7260571f42ea65c6622aa6b410a0e43b28
This prevents version conflicts when Keystone drags in a too-new
oslo.policy, which blackballs latest requests (but Sphinx would try to
pull it in anyway).
Change-Id: I3b2196fdef9936f1c7d468f9c7c9b9246d3d26fd
Previously, s3token would make one request to Keystone to validate the
request signature provided by the user, then use the response to add an
X-Auth-Token header to the request environment. This would get picked up
by the authtoken middleware which would make *another* request to
validate the token *we just got*.
Now, we'll populate the request environment with the following headers:
* X-Identity-Status
* X-Roles
* X-User-Id
* X-User-Name
* X-Tenant-Id
* X-Tenant-Name
* X-Project-Id
* X-Project-Name
This allows Swift's keystoneauth middleware to function without needing
the authtoken middleware at all.
UpgradeImpact
-------------
The recommended pipeline ordering has changed. Whereas authoken previously
had to be between s3token and keystoneauth like
... swift3 s3token authtoken keystoneauth ...
it should now be placed before swift3, as in
... authtoken swift3 s3token keystoneauth ...
Alternatively, if Keystone users should only ever access Swift through
the S3 API, the authtoken middleware may be removed entirely. Note that
the old pipeline ordering will continue to work, but still requires two
Keystone requests per client request as before.
To upgrade an existing cluster to take advantage of this change
operators should, for each proxy server:
1. Upgrade swift3
2. Optionally, restart proxy-server
3. Update proxy-server.conf with the new pipeline
4. Restart proxy-server
Updating proxy-server.conf *before* upgrading swift3 will prevent the
proxy from starting if there is an unexpected reboot before the upgrade.
Closes-Bug: #1653017
Change-Id: I21e38884a2aefbb94b76c76deccd815f01db7362
...because the alternative is to add pins for one or more of
* osc-lib
* os-client-config
* cliff
* whatever else...
Also drop the unused OS_* env vars, as they make more-recent
python-openstackclient barf with
TypeError: __init__() got an unexpected keyword argument 'project_name'
Change-Id: Ibfda43cfc28b5aa6530d4ab3a87a7bc696b9ca7c
The combination of select and ignore options doesn't do what we want,
anyway. Now, we won't regress on a number of issues, like H234, H235,
and E127.
Also added H237 to ignore list, as we currently trip
module multifile is removed in Python 3
... in test/functional/test_object.py
Change-Id: Id746552bc024e726e29105c077057e46e248a0a8
Related-Change: I41d63b9467083d7606ad18aaa398ca7738b27fae
This patch moves (as discussed at the Newton design summit) the
s3_token middleware from keystonemiddleware to swift3. The git
history is not included based upon the agreement between the
Keystone team and the Swift3 team.
This is based on s3_token.py from openstack/keystonemiddleware@234913e
Note that the egg entrypoint has changed from "s3_token" to "s3token"
for consistency between entrypoint and recommended pipeline names.
Additionally, keystone functional tests now use the in-tree s3token
middleware.
Upgrade Impact
==============
Deployers currently using keystone for authentication should change
their s3token filter definition to use the middleware provided by swift3
rather than the one provided by keystonemiddleware. Note that
keystonemiddleware will still need to be installed, and its auth_token
middleware configured.
UpgradeImpact
Co-Authored-By: Tim Burke <tim.burke@gmail.com>
Co-Authored-By: Kota Tsuyuzaki <tsuyuzaki.kota@lab.ntt.co.jp>
Change-Id: I1c0e68a5276dd3dee97d7569e477c784db8ccb8a
When delete a object created by Complete Multipart Upload in Delete
Multiple Objects operation, delete both manifest file and segments by
adding "multipart-manifest=delete" to query string.
Change-Id: I3759e6f43d8c531d7a7d961c2069af1e411d04ef
According to [1] when an Authorization header is specified, either a
Date or x-amz-date header needs to be specified, with the x-amz-date
header taking precedence.
Now, the x-amz-date header is validated first, and if both headers are
missing, an AccessDenied error should be returned. This should prevent
replay attacks occurring on valid requests that are missing the Date
header.
[1]
http://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonRequestHeaders.
html
N.B. This also fixes some pylint issues and dependencies
Closes-Bug: 1497424
SecurityImpact
[CVE-2015-8466]
Co-Authored-By: Darryl Tam <dtam@swiftstack.com>
Co-Authored-By: Tim Burke <tim.burke@gmail.com>
Change-Id: Ibeff8503fa147e1cf08c1b5374aecee7a4c0bee2
I change functional tests to the new structure using nosetests.
Existing functional tests has the following problems.
- File name becomes the nonsense sequence number.
- Large quantity of files will be located in one directory when we add tests because it becomes 1 file every 1 test.
- Because the system is such that it is more special than other products of OpenStack, it is hard to develop it.
I think that the problem mentioned above are solved by this patch.
Change-Id: Ic75858ca1894e19f12c37b25559354f65fb48fa6
This patch adds a basic support for S3 Multipart Upload APIs based on Swift3
static large objects. The s3multi middleware is no longer necessary.
There are still many TODO items. They are commented in the source code.
Change-Id: Icda01dc31de43e6fe36144921fa1bd276b76e5ea
This patch adds an xfstests-style functional test suite. Run "tox -e tempauth"
to test swift3 with TempAuth, and "tox -e keystone" to test with the Keystone
auth system. You don't need to prepare Swift and Keystone system for that.
They will be started with minimum configuration automatically.
If you already have a Swift cluster for the functional test, run "./check" in
the test directory directly. Individual tests can be run using "./check 003",
and various other options are also supported. Try "./check -h" for more
information.
I added some sample test cases but they are not enough at all obviously. More
tests will be added soon.
Change-Id: I75abce574768abbe88f60d8c1eee87757651e357
Tim Burke