Previous doc string describes "http_conn" for a bunch of functions as
"HTTPConnection object" but it is actually "a tuple of (parsed_url,
HTTPConnection object)" so now this patch correct the mis-consistency.
Change-Id: I6ff90a941e6df6a1b3b5dc74fd5f4262654c9f0a
The existing test that os-identity-api-version=2 would
result in the correct auth_version=2.0 (note 2 -> 2.0)
does not verify the sloppy version handling code path.
When auth, key and user options are all missing the
auth version is always set to 2.0 so the test will always
pass. Adding auth, key and user options to the test command
will cause the test to verify that the os-identity-api-version
option was used and mapped to 2.0.
Change-Id: Ifa10cd2b8bf81c082d5e3fa846f993871194fea0
Previously, if a Range request came back 200 OK (rather than 206 Partial
Content), we would mangle the response body. This could happen if there
was a middleware that would silently drop Range headers, for example.
Now, if the response does not include a Content-Range header, we will
log a warning and seek to our previous position in the stream. If the
Content-Range header has an unexpected value, we will raise an exception.
Change-Id: I94d4536cc1489968d45a2b6ba7edd70c85800275
As a result of the Hackathon we have produced a new
documentation structure for the python-swiftclient.
This patch introduces the new structure and adds the
required content.
The intention is to document the CLI, the SwiftService
and Connection API. Importantly, we also provide
guidance on important considerations when using a swift
object store, such as which aspect of the python-swiftclient
to use for various use cases, common authentication patterns
and some useful examples.
Co-Authored-By: Alexandra Settle <alexandra.settle@rackspace.com>
Co-Authored-By: Mohit Motiani <mohit.motiani@intel.com>
Co-Authored-By: Hisashi Osanai <osanai.hisashi@jp.fujitsu.com>
Change-Id: I9eb41f8e9137efa66cead67dc264a76a3c03fbda
The documentation of "swift download" hints that "marker" option
is supported, but in reality we forgot to patch it through, so
all downloads were always done with the default, empty marker.
Closes-Bug: #1565393
Change-Id: I38bd29d2baa9188b61397dec75ce1d864041653c
Previously, we were using a content-type of text/directory, but that is
already defined in RFC 2425 and doesn't reflect our usage:
The text/directory Content-Type is defined for holding a variety
of directory information, for example, name, or email address,
or logo.
(From there it goes on to describe a superset of the vCard format
defined in RFC 2426.)
application/directory, on the other hand, is used by Static Web [1] and
is used by cloudfuse [2]. Seems like as sane a choice as any to
standardize on.
[1] https://github.com/openstack/swift/blob/2.5.0/swift/common/middleware/staticweb.py#L71-L75
[2] https://github.com/redbo/cloudfuse/blob/1.0/README#L105-L106
Change-Id: I19e30484270886292d83f50e7ee997b6e1623ec7
...using a new "application/swiftclient-segment" content-type.
Segments uploaded by swiftclient are expected to have a many-to-one
relationship to large objects, rather than the more-general many-to-many
relationship that SLO and DLO generally allow. Later, we may use this
information to make more intelligent decisions, such as when to
automatically clean up segments.
Change-Id: Ie56a3aa10065db754ac572cc37d93f2c901aac60
Why now?
* argparse was introduced in Python 3.2 and back-ported to Python 2.7.
Until we dropped Python 2.6 support, we were stuck on optparse.
* keystoneauth.loading.cli provides register_argparse_arguments and
load_from_argparse_arguments helper methods. Now that we're moving
toward Keystone Session support, argparse seems required.
Closes-Bug: 1553030
Change-Id: I5139fb64a8631a3010680090fd04345f95c55c7b
SwiftService().post(cont, [SwiftPostObject(obj, options]) currently
ignores options['header'], raises exception when options['headers']
is set and make malformed metadata when options['meta'] is set.
Fix tipos in code, add unittest for SwiftService().post
Closes-Bug: #1560052
Change-Id: Ie460f753492e9b73836b4adfc7c9c0f2130a8a91
Previously, we'd occasionally get spurious failures like
FAIL: test_delete_account (tests.unit.test_shell.TestShell)
----------------------------------------------------------------------
Traceback (most recent call last):
File ".../mock/mock.py", line 1721, in _inner
return f(*args, **kw)
File ".../mock/mock.py", line 1305, in patched
return func(*args, **keywargs)
File ".../tests/unit/test_shell.py", line 788, in test_delete_account
response_dict={})], any_order=True)
File ".../mock/mock.py", line 983, in assert_has_calls
), cause)
File ".../six.py", line 718, in raise_from
raise value
AssertionError: (call(u'container', u'object', query_string=None,
response_dict={}),)
not all found in call list
Related-Bug: #1539536
Related-Bug: #1480223
Change-Id: I810894545ca74d3b2f2dbde2d0388eb69c2ba710
Fix the linked bug. delete_object mock should be before it's
called by swiftclient.shell.main function.
Related: https://review.openstack.org/221219
Change-Id: I52143a93c129764c02bba05267f3563c824e82cb
Partial-Bug: #1480223
Now, client applications can get to things like transaction IDs for
failures without needing to turn on all of logging.
While we're at it, add a from_response factory method for
ClientException.
Co-Authored-By: Alexander Corwin <ancorwin@gmail.com>
Change-Id: Ib46d5f8fc7f36f651f5908bb9d900316fdaebce3
See change I74fb5122e80a223aaa70afaeec7a7c585aa33577 for the
previous discussion. But basically, if you run tox -e py27
then tox -e py34, the latter fails with "db type could not
be determined", because of stuck .testrepository/times.dbm.
This patch fixes it by clearing the *.dbm*. Should be safe
as long as periods aren't used commonly in stable file names.
Change-Id: I617eca308261f291c510c8cbd432779f1c00b182
in python-swiftclient/swiftclient/service.py,
there is a method
def download(self, container=None, objects=None, options=None):
if container is specified but objects not, it download all
objects in specified container.
if both container and objects are specified, it download all
specified objects in the container.
when it comes to the case that, objects argument is specified,
but it turned out to be empty array [ ], the download method
download all the objects under specified container.
this may be not reasonable.
for example,
the objects was not empty when it came from command line,
but it's filtered, maybe by --prefix argument.
at last, it turned out to be empty array.
when calling download method with objects arguments
being empty array, we should download nothing instead of
all the objects under the specified container.
Change-Id: I81aab935533a50b40679c8b3575f298c285233a8
Closes-bug: #1549881
