Implement copy object method in swiftclient Connection, Service and CLI.
Although COPY functionality can be accomplished with 'X-Copy-From'
header in PUT request, using copy is more convenient especially when
using copy for updating object metadata non-destructively.
Closes-Bug: 1474939
Change-Id: I1338ac411f418f4adb3d06753d044a484a7f32a4
This lets us do things like:
$ swift info --json | jq '[.swift.policies[].name]'
[
"Standard-Replica",
"EC"
]
Also, escape more dashes in the man page, so they won't be
misinterpreted as hyphens.
Change-Id: Ic7690bdbcfc55f55e5dde9bc11bb0644085973ce
The user already knows this is insecure, there's no point in bringing it
up again and again.
See also: https://github.com/kennethreitz/requests/issues/2214
Change-Id: I7991b2e568407269f84138bc03711147ed080c9c
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
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
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
My understanding is that it was mainly being used so we could have sane
testing on py26. With py26 support being dropped, we no longer need it.
Also drop discover from test-requirements.txt, as we don't seem to
actually use it.
Change-Id: Iee04c42890596d3b483c1473169480a3ae19aac8
Related-Change: I37116731db11449d0c374a6a83a3a43789a19d5f
Add support for the auth-version to be specified using
--os-identity-api-version or OS_IDENTITY_API_VERSION
for compatibility with other openstack client command
line options.
The auth version used will be selected as follows:
- if either --auth-version or --os-identity-api-version
is set, use that value
- otherwise use the value of ST_AUTH_VERSION, if set
- otherwise use the value of OS_AUTH_VERSION, if set
- otherwise (new behaviour) use the value of
OS_IDENTITY_API_VERSION, if set
- otherwise default to 1.0
Note that before this change the auth version might have
defaulted to 1.0 despite OS_IDENTITY_API_VERSION being set,
but with this change OS_IDENTITY_API_VERSION is preferred.
Change-Id: Ifba4c4e43560ede3013337b8cdbc77dc2de6e8ff
Closes-Bug: #1541273
This fix ensures creation and use of the correct default segment
container when pseudo-folder paths are passed via <container> arg.
Change-Id: I90356b041dc9dfbd55eb341271975621759476b9
Closes-Bug: 1532981
Related-Bug: 1478210
The test asserts calls made in specific order,
but they are made from threads so may be in
different order.
Change-Id: I1b6e7303fe0e6fb2afc7da3462b891feab90bc17
Closes-Bug: #1539536
The test asserts calls made in specific order,
but they are made from threads so may be in
different order.
Change-Id: I857ad3b909c3b635927fb1a39682d66d20c6fd59
Previously, the following empty directories would be created:
* container
* container/pseudo
* pseudo
Change-Id: I002e2da8d28a873728e0b5c2d33f94f21132d058
When issuing `delete` commands that would require three or more
individual deletes, check whether the cluster supports bulk deletes
and use that if it's available.
Additionally, a new option is added to the `delete` command:
* --prefix <prefix>
Delete all objects that start with <prefix>. This is similar to the
--prefix option for the `list` command.
Example:
$ swift delete c --prefix obj_prefix/
...will delete from container "c" all objects whose name begins with
"obj_prefix/", such as "obj_prefix/foo" and "obj_prefix/bar".
Change-Id: I6b9504848d6ef562cf4f570bbcd17db4e3da8264
This fix makes it possible to upload objects to pseudo-folders by
passing the upload paths via <container> arg regardless of whether the
container or folder path exist or not.
Change-Id: I575e58aa12adcf71cdaa70d025a0ea5c63f46903
Closes-Bug: #1478210
Partial-Bug: #1432734
Related-Bug: #1432734
The debug and info options need to be set before a subcommand method is called,
otherwise they are simply ignored. This is kind of irritating - other options
(for example -U, -A, -K) are usable after a positional command.
This patch fixes this, and commands like these are no longer ignoring --debug or --info:
swift stat --debug
swift list container --info
Co-Authored-By: Alistair Coles <alistair.coles@hpe.com>
Change-Id: Ib19b05deef7a015881f1eed4a3946025e16bf922
It was dropping warnings like "UserWarning: Providing attr without
filter_value to get_urls() is deprecated as of the 1.7.0 release and may
be removed in the 2.0.0 release. Either both should be provided or
neither should be provided."
Change-Id: Iead0bcf36b4a46bf465a55a33a21fd7f14f0ac40
* Always use testtools.TestCase, since we're relying on testtools
* Always use mock (as opposed to unittest.mock) since we're relying on
mock
* Add note about when a missing logging handler was added
* Stop %-formatting the giant usage string that doesn't actually need
any formatting
* Prefer assertIs, assertIn, assertIsInstance over assertTrue
* Use else-self.fail instead of sentinel values
* Check resp.get('error') is None before checking resp['success'] is
True, so test failures actually tell you something useful
* Tighten some isinstance assertions
* Import MockHttpTest from correct location
* Only populate clean_os_environ once
* Use setUp for setup, not __init__
* Replace assertIn(key, dict) and assertEqual(foo, dict[key]) with
assertEqual(foo, dict.get(key)) when key is a literal and foo is not
None
* Use mock.patch.object instead of manually patching for tests
* Use six.binary_type instead of type(''.encode('utf-8'))
* Stop shadowing builtin bytes
* Reclaim some margin
* Stop checking the return-type of encode_utf8; we already know it's
bytes
Change-Id: I2138ea553378ce88810b7353147c8645a8f8c90e
Attempt to fix the linked bug by initialising the mock instance for
Connection.delete_object before calling the SwiftService upload
method, so that the delete_object mock already exists before the
delete_segments jobs that run in multiple threads call it. Otherwise
there is a risk that the delete_segment job threads could race while
creating either the delete_object mock or the
delete_object.return_value mock, resulting in each thread getting a
different instance. That would explain the intermittent test failures
reported in the bug.
Change-Id: Ia82697c093529076b0bbcc6bccd577afdf0839e1
Partial-Bug: #1480223
The `tempurl` subcommand's second positional argument is called
`seconds` and has heretofore interpreted as the number of seconds for
which the tempURL should be valid, counting from the moment of running
the command. This is indeed a common, if not the most common,
use-case. But some users, occasionally, might want to generate a tempURL
that expires at some particular ("absolute") time, rather than a
particular amount of time relative to the moment of happening to run the
command. (One might make an analogy to the way in which Swift's expiring
object support supports an `X-Delete-At` header in addition to
`X-Delete-After`—and it's the former that must be regarded as
ontologically prior.) Thus, this commit adds an `--absolute` optional
argument to the `tempurl` subcommand; if present, the `seconds` argument
will be interpreted as a Unix timestamp of when the tempURL should be
expire, rather than a duration for which the tempURL should be valid
starting from "now".
Change-Id: If9ded96f2799800958d5063127f3de812f50ef06
Some improvements to the tests for staggered download
that were added in [1].
[1] Ie737cbb7f8b1fa8a79bbb88914730b05aa7f2906
Change-Id: Ib999bc7bd198c1d9c217c57501f751e854d4c6ad
