Adding a trailing slash to the authentication URL may interfere with
auth service implementations not using /FOO/ but /FOO as authentication
URL.
OpenStack Object Storage API 1.0 doesn't specify that the auth URL must
end in a slash and swiftclient.client doesn't force it either.
Change-Id: I4e6b6d758d5ccc884e253880513e3d8763ffc2ff
Fixes: bug #1085827
str(float) isn't a good way of converting a float to a string with all the precision
Eg
>>> f = os.path.getmtime("z")
>>> f
1347717491.343554
>>> str(f)
'1347717491.34'
>>> "%f" % f
'1347717491.343554'
Change-Id: I6eb02f7f6730eff814c348d1039eae4606642b52
Fixes Bug #1052161
"python setup.py build" fails on Windows due to a hardcoded shell path:
/bin/sh
setup.py updated using openstack-common/update.py
Change-Id: I763dd5613d91a2523087173b196500648c477fa6
This patch forces swiftclient to encode to utf-8
all url and headers arguments, to avoid the
UnicodeDecodeError which is raised by '\r\n'.join([])
invoked in htplib.py.
Currently the affected projects are Horizon(upload file
with unicode name) and swiftclient CLI('swift post' with
unicode filename as header)
This is also a follow-up of this review:
https://review.openstack.org/#/c/14216/
I'd still want to hear what the Swift core devs
think of it. Is it better to create a new
AutoEncodingHTTPConnection? Or to handle the connection
creation and make sure there are no unicode and utf-8
string at the same time. If these unicode checks have to
be added in the calling code(Dashboard, CLI), there are
so many places to be added, and also in all new commands
that might be exposed from the API.
Fixes bug 1008940
Change-Id: Ice2aa29024429d3e6f569a88d5cf8b4202537827
Default the authurl/user/key constructor arguments for the
Connection class to None, as these are not required in the
preauthurl/preauthtoken case
Change-Id: I445a5d365212c365ecc691c0a670a226e2b7954a
Add trove classifier to have the client listed among the
other OpenStack-related projets on PyPI.
Change-Id: I7b2a9b0e163b79593662bfa799f076f538e3d7ca
Signed-off-by: Doug Hellmann <doug.hellmann@dreamhost.com>
Add --os-region-name (and OS_REGION_NAME env) to bin/swift
Add region_name to the os_options in Connection class.
bug 1019832
Change-Id: Id8515d97e5351638dce10581c7368f61518e1fa7
This patch adds a "--no-download" option to the "download" command.
When given, all writing to disk is bypassed, while still actually
downloading the data and validating etags.
This can be handy when you're using the swift command-line client to
test out a swift cluster and don't want client-side disk writing to be a
bottle-neck (but you still want to know about any etag validation
failures).
Change-Id: I0a511f473a64820161d1eb529b995900742794f2
This changes every command-line option with a '_' in its name
and changes them to '-'. The old option names are maintained
for backward compatibility but are no longer in the help text.
BP command-options
Change-Id: I79b3c03f59ce8e253aa0dcbf0c2ed5a56d71cd0c
Description: The swift command tool will set the auth version
to 2 if OS_AUTH_URL is set even use -V 1 option to set Version
to 1.So when use nova/glance client and swift client in the
same shell, and export environment OS_AUTH_URL, it will lead
swift client to raise 400 error if swift not use keystone
for auth.
Fixes bug 1034158
Change-Id: I8003ff2ad4ac25fd710f87c4dab1507f6040ed3d
Adding nosehtmloutput as a test dependency allows nose to output its
results to an html file. This will be used by Jenkins to save logs on
a different server.
Change-Id: I4292ba27db9371d5a8dae4b901a46165b9ee6721
When downloading the same containers or objects with multiple
invocations of the swift command-line client, you'll get better
throughput and avoid "hot spots" if each client randomizes its download
order.
Note that the marker must be picked *before* shuffling the containers or
objects.
Change-Id: I7240eda57a80e1708c2483827c6329fd57d5fc51
When using the swift command-line tool to evaluate a Swift cluster, it
can be very handy to get some insight into the download timing. This
patch adds timing data to verbose output for the download command. For
each downloaded file, the printed line will also contain:
- The time it took to send the request and receive the header
- The total time the request took (including writing the file out
locally)
- The average throughput of the download
Change-Id: Ib4a995623af973bb1eed4fb52c8c0e5da935964d
Fix race condition in _delete_container() where all elements of
object_queue have been removed, but the last one (per thread) may not
have actually been deleted yet when the container deletion thread calls
conn.delete_container(container). Fixes bug 1032879.
Improves container deletion throughput by immediately deleting
containers with no objects instead of waiting for all pending object
deletes to complete. Fixes bug 1032878.
Change-Id: I404229a4c608995294e0ada77724ac8afe8d6f3c
Documenation builds specify a version in doc/source/conf.py that is
used in appropriate places through out the documentation. Previously
this value had not been defined properly and documentation builds
failed. Retrieve the version info using pkg_resources and set it
properly.
Use openstack.common.version to consume the generated version information
for documentation. Additional, add a swiftclient.__version__ member which
will return the version of swiftclient being used.
Change-Id: I14f3abdf00da3f9ea7d0651efe76b08f69ddabae
- This allows us to delegate all 2.0 authentication directly to the
library without reimplementing ourselves.
- Support reusing a token / storage-url without re-authenticating every
time via the switch os_storage_url os_auth_token.
- Allow auth via tenant_id instead of just tenant_name via the switch
os_tenant_id.
- Refactor a bit to make it easier in the future to add new OS features
(i.e: region).
- Implements blueprint use-keystoneclient-for-swiftclient.
- Fixes bug 1016641.
Change-Id: I532f38a68af884de25326aaac05a2050f5ffa1c7
The 'delete', 'download', and 'upload' commands use multiple threads
for concurrency. However, the number of threads was hardcoded at
10. This patch simply makes those configurable.
For example, if I'm downloading a lot of files but I don't want to
saturate the downstream on my Internet connection, I might choose to
use only 1 or 2 threads for object downloads. Conversely, if I'm
uploading a lot of small files across a fast network, I would want
lots of threads to speed things along.
The default number of threads is 10, so the default behavior is
unchanged.
Change-Id: I64c06741b24ca97fef5ded206d7e898bf5cab3b8