| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
Change-Id: I669533334419e94ca925e859f2b0d5d2afe9f7f1
|
| |\ |
|
| | |
| |
| |
| | |
Change-Id: I3dac826c1f208569c5f40431f59a2045e5744415
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, when deleting a symlink that points to an xLO, we'd clean
up the xLO's segments then delete the symlink, leaving the xLO itself
busted.
Similar trouble would come from overwriting a symlink pointing to an
xLO. Check for a Content-Location in the HEAD response and leave such
segments.
Co-Authored-By: Clay Gerrard <clay.gerrard@gmail.com>
Change-Id: I45b210cf380a68bd88187c91fa2d63a8b2bb709b
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Symlinks have recently added some new keys to container listings. It's
very convenient to be able to see and reason about the extra information
in container listings.
Allowing raw json output is similar with what the client already does
for the info command, and it's forward compatible with any listing
enhancements added by future middleware development.
Change-Id: I88fb38529342ac4e4198aeccd2f10c69c7396704
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| | |
Because it should take a value of either realm or full url.
Change-Id: I1fe30825ef1620e256c9fd3057da6808b03d7200
|
| |\ \ |
|
| | | |
| | |
| | |
| | | |
Change-Id: I18a6327b3acdd4db5ae80097080c043f7c20c353
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, if you uploaded a file as an SLO then re-uploaded it
with the same segment size and mtime, the second upload would
go delete the segments it just (re)uploaded. This was due to
us tracking old_slo_manifest_paths and new_slo_manifest_paths
in different formats; one would have a leading slash while the
other would not.
Now, normalize to the stripped-slash version so we stop deleting
segments we just uploaded.
Change-Id: Ibcbed3df4febe81cdf13855656e2daaca8d521b4
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
...since modern sphinx won't install on py27.
While we're at it, clean up some warnings and treat warnings as errors.
Also, fix up how we parse test configs so we can run func tests.
Related-Change: Id3c2ed87230c5918c18e2c01d086df8157f036b1
Change-Id: I3718f69610545b0dbcb0a2ab45b400da3a45682c
|
| | |
| |
| |
| | |
Change-Id: I89255f6923c649c7b9d3d36e96c09f8bc4f51a3c
|
| | |
| |
| |
| |
| |
| |
| | |
1. update hacking version to latest
2. fix pep8 failed
Change-Id: Ifc3bfeff4038c93d8c8cf2c9d7814c3003e73504
|
| | |
| |
| |
| |
| |
| |
| | |
Exposes the delimiter parameter, which the Swift API supports for
container listings.
Change-Id: Id8dfce01a9b64de9d1222aab9a4a682ce9e0f2b7
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While investigating the failures when you move func tests to py3, I
noticed a whole bunch of
ResourceWarning: unclosed <socket.socket ...>
noise. This should fix it.
While we're at it, make get_capabilities less stupid.
Change-Id: I3913e9334090b04a78143e0b70f621aad30fc642
Related-Change: I86d24104033b490a35178fc504d88c1e4a566628
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There were two basic problems:
- We'd try to import on every attempt at getting auth, even when we
already know keystoneclient isn't available.
- Sometimes devs would hit some crazy import race involving (some
combination of?) greenthreads and OS threads.
So let's just try the imports *once*, at import time, and have None
sentinels if it fails. Try both versions separately to decouple
failures; this should let us support a wider range of keystoneclient
versions.
Change-Id: I2367310aac74f1b7c5ea0cb1a822a491e4ba8e68
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since we define the getheader() method on the response from
HTTPConnection, we don't have to call parse_header_string, as the values
will already be converted properly.
Change-Id: Ia81e8674b828b3ff1f014454126b469e41adfc23
|
| |\ \ \
| |/ /
|/| | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I'm giving up on trying to back out all of the test-requirements
up-revs, but let's try to stay compatibile with old requests/six.
As part of that, only disable some requests warnings on new-enough requests.
Note that we should now be compatible with distro packages back to
Ubuntu 16.04 and CentOS 6. Our six is still too new for Trusty, but
hey, there's less than a year left on that anyway, right?
Change-Id: Iccb23638393616f9ec3da660dd5e39ea4ea94220
Related-Change: I2a8f465c8b08370517cbec857933b08fca94ca38
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix unicode handling in Python 3 and Python 2. There are currently two
failure modes. In python 2, swiftclient fails to log in debug mode if
the account name has a non-ASCII character. This is because the account
name will appear in the storage URL, which we attempt to pass to the
logger as a byte string (whereas it should be a unicode string). This
patch changes the behavior to convert the path strings into unicode by
calling the parse_header_string() function.
The second failure mode is with Python 3, where http_lib returns headers
that are latin-1 encoded, but swiftclient expects UTF-8. The patch
automatically converts headers from latin-1 (iso-8859-1) to UTF-8, so
that we can properly handle non-ASCII headers in responses.
Change-Id: Ifa7f3d5af71bde8127129f1f8603772d80d063c1
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
Allows clients to give up on reading the rest of the server response,
if they so choose.
Change-Id: Iccc95b1b5e7d066470966ee0c62a3beb260846e5
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | | |
Change-Id: Ia1638c216eff9db6fbe416bc0570c27cfdcfe730
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This patch basically follows the bash completion
model that other OpenStack clients use. It creates
a new command to swiftclient called `bash_completion`.
The `bash_completion` command by default will print
all base flags and exsiting commands. If you pass
it a command, it'll print out all base flags and
any flags that command accepts. So as you type out
your swift command and auto-complete, only the current
available flags are offered to you.
This is used by the swift.bash_completion script to
allow swift commands to be bash completed.
To make it work, place the swift.bash_completion file
into /etc/bash_completion.d and source it:
cp tools/swift.bash_completion /etc/bash_completion.d/swift
source /etc/bash_completion.d/swift
Because swiftclient itself is creating this flag/command output
it should automatically add anything we add to the swiftclient
CLI.
Change-Id: I5609a19018269762b4640403daae5827bb9ad724
|
| |\ \ \ \ |
|
| | | |_|/
| |/| |
| | | |
| | | | |
Change-Id: I76be70ddb289bd4f1054a684a247279ab16ca34a
|
| | |_|/
|/| |
| | |
| | |
| | |
| | | |
IP range restriction
Change-Id: I4734599886e4f4a563162390d0ff3bb1ef639db4
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Add the --prompt option for the CLI which will cause the user to be
prompted to enter a password. Any password otherwise specified by
--key, --os-password or an environment variable will be ignored.
The swift client will exit with a warning if the password cannot be
entered without its value being echoed.
Closes-Bug: #1357562
Change-Id: I513647eed460007617f129691069c6fb1bfe62d7
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
An earlier change added support for versionless authurls, but the
huristic to detect them didn't work for some configurations I've
encountered.
Now we use a little bit tighter pattern matching and support auth_url
values with more than one path component.
Change-Id: I5a99c7b4e957ee7c8a5b5470477db49ab2ddba4b
Related-Change-Id: If7ecb67776cb77828f93ad8278cc5040015216b7
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The valid set of values for auth_version does not include
values starting with the 'v'.
In this particular function, the auth_version variable is
only used for comparisons with v3. So, the code worked
correctly. However, let's clean this up in order to reduce
review confusion and defuse possible future landmine in case
of code changes.
Change-Id: I671016d7992a1922b786b4eb8876b3fbb2532e15
|
| |\ \ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
ading multiple options on the same line makes
it easy to miss when quickly scanning the options.
Change-Id: I8e324fca48cd05d9e381d5106135542274c2ff7f
Signed-off-by: Thiago da Silva <thiago@redhat.com>
|
| | |/ / /
|/| | |
| | | |
| | | | |
Change-Id: I94aca6f1120c34616562be7345f0e5aa51a69499
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch attemps to add an option to force get_auth call while retrying
an operation even if it gets errors other than 401 Unauthorized.
Why we need this:
The main reason why we need this is current python-swiftclient requests could
never get succeeded under certion situation using third party proxies/load balancers
between the client and swift-proxy server. I think, it would be general situation
of the use case.
Specifically describing nginx case, the nginx can close the socket from the client
when the response code from swift is not 2xx series. In default, nginx can wait the
buffers from the client for a while (default 30s)[1] but after the time past, nginx
will close the socket immediately. Unfortunately, if python-swiftclient has still been
sending the data into the socket, python-swiftclient will get socket error (EPIPE,
BrokenPipe). From the swiftclient perspective, this is absolutely not an auth error,
so current python-swiftclient will continue to retry without re-auth.
However, if the root cause is sort of 401 (i.e. nginx got 401 unauthorized from the
swift-proxy because of token expiration), swiftclient will loop 401 -> EPIPE -> 401...
until it consume the max retry times.
In particlar, less time to live of the token and multipart object upload with large
segments could not get succeeded as below:
Connection Model:
python-swiftclient -> nginx -> swift-proxy -> swift-backend
Case: Try to create slo with large segments and the auth token expired with 1 hour
1. client create a connection to nginx with successful response from swift-proxy and its auth
2. client continue to put large segment objects
(e.g. 1~5GB for each and the total would 20~30GB, i.e. 20~30 segments)
3. after some of segments uploaded, 1 hour past but client is still trying to
send remaining segment objects.
4. nginx got 401 from swift-proxy for a request and wait that the connection is closed
from the client but timeout past because the python-swiftclient is still sending much data
into the socket before reading the 401 response.
5. client got socket error because nginx closed the connection during sending the buffer.
6. client retries a new connection to nginx without re-auth...
<loop 4-6>
7. finally python-swiftclient failed with socket error (Broken Pipe)
In operational perspective, setting longer timeout for lingering close would be an option but
it's not complete solution because any other proxy/LB may not support the options.
If we actually do THE RIGHT THING in python-swiftclient, we should send expects: 100-continue
header and handle the first response to re-auth correctly.
HOWEVER, the current python's httplib and requests module used by python-swiftclient doesn't
support expects: 100-continue header [2] and the thread proposed a fix [3] is not super active.
And we know the reason we depends on the library is to fix a security issue that existed
in older python-swiftclient [4] so that we should touch around it super carefully.
In the reality, as the hot fix, this patch try to mitigate the unfortunate situation
described above WITHOUT 100-continue fix, just users can force to re-auth when any errors
occurred during the retries that can be accepted in the upstream.
1: http://nginx.org/en/docs/http/ngx_http_core_module.html#lingering_close
2: https://github.com/requests/requests/issues/713
3: https://bugs.python.org/issue1346874
4: https://review.openstack.org/#/c/69187/
Change-Id: I3470b56e3f9cf9cdb8c2fc2a94b2c551927a3440
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
Submitting a path parameter with a HEAD request on an object can be
useful if one is trying to find out information about an SLO/DLO without
retrieving the manifest.
Change-Id: I39efd098e72bd31de271ac51d4d75381929c9638
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When uploading from standard input, swiftclient should turn the upload
into an SLO in the case of large objects. This patch picks the
threshold as 10MB (and uses that as the default segment size). The
consumers can also supply the --segment-size option to alter that
threshold and the SLO segment size. The patch does buffer one segment
in memory (which is why 10MB default was chosen).
(test is updated)
Change-Id: Ib13e0b687bc85930c29fe9f151cf96bc53b2e594
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, the --meta option was only allowed on post or copy subcommands.
Change-Id: I87bf0338c34b5e89aa946505bee68dbeb37d784c
Closes-Bug: #1616238
|
| |\ \ \
| |_|/
|/| | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Newer deployments are using versionless Keystone endpoints, and most
OpenStack clients already support this.
This patch enables this for Swift: if an auth_url without any path
component is found, it assumes a versionless endpoint will be used.
In this case the v3 suffix will be appended to the path if none
auth_version is set, and v2.0 is appended if auth_version requires v2.
Closes-Bug: 1554885
Related-Bug: 1691106
Change-Id: If7ecb67776cb77828f93ad8278cc5040015216b7
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If "-" is passed in for the source, python-swiftclient will upload
the object by reading the contents of the standard input. The object
name option must be set, as well, and this cannot be used in
conjunction with other files.
This approach stores the entire contents as one object. A follow on
patch will change this behavior to upload from standard input as SLO,
unless the segment size is larger than the content size.
Change-Id: I1a8be6377de06f702e0f336a5a593408ed49be02
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Otherwise, Python defaults to 8k reads which seems kinda terrible.
Change-Id: I3160626e947083af487fd1c3cb0aa6a62646527b
Closes-Bug: #1671621
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently, the swiftclient upload command passes a custom metadata
header for each object (called object-meta-mtime), whose value is
the current UNIX timestamp. When downloading such an object with the
swiftclient, the mtime header is parsed and passed as the atime and
mtime for the newly created file.
There are use-cases where this is not desired, for example when using
tmp or scratch directories in which files older than a specific date
are deleted. This commit provides a boolean option for ignoring the
mtime header.
Change-Id: If60b389aa910c6f1969b999b5d3b6d0940375686
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If we get back some partial content, we can't validate the MD5.
That's OK.
Change-Id: Ic1d65272190af0d3d982f3cd06833cac5c791a1e
Closes-Bug: 1642021
|