I just noticed tonight when adding a bunch of stuff to Swiftly that
the Bulk Delete middleware uses an account-level DELETE request,
albeit with a query parameter of bulk-delete. But, one typo and,
assuming the cluster supports it and you have access, whoops, you
just marked the account for deletion!
I put a bit of extra safety on the account deletion by requiring it
to have an empty query string.
Change-Id: Ib5df11193b04eff69d14185bd9d0607169131e7f
If mount_check is true (ie an SAIO with "real "devices, not loopback),
then the servers will correctly return 507 when given a nonsense path.
The first element is treated as a drive path, and that path isn't
mounted. This patch adds 507 as a valid status response to the server
check.
Change-Id: I1d1bb0ab78fd9ea17323635da7e686182fbdbf13
account_quota middleware fails to check if account_info exists
after retrieving it.
Change-Id: I1aa492d3bd713a6bf27e18ef4ec2e29f4cfb694d
Fixes: Bug #1167389
The trans_id_suffix (default is empty) would be appended to the swift transaction
id allowing one to easily figure out from which cluster that X-Trans-Id
belongs to. This is very useful when one is managing more than one swift
cluster. Also updated sample and manpage to reflect the changes.
Change-Id: Icdf63643e9c1bde36a9ef5e3f41ee9fb20e55f5d
This patch identifies md5 collisions on objects and sends a 403
from the object server.
Credits for originating this fix are to Michael Factor.
Change-Id: I4f1b32183e2be6bbea56eaff86b9a4c7f440804a
Fix: Bug #1157454
Extensive refactor here to consolidate what nodes are contacted for
any request. This consolidation means reads will contact the same set
of nodes that writes would, giving a very good chance that
read-your-write behavior will succeed. This also means that writes
will not necessarily try all nodes in the cluster as it would
previously, which really wasn't desirable anyway. (If you really want
that, you can set request_node_count to a really big number, but
understand that also means reads will contact every node looking for
something that might not exist.)
* Added a request_node_count proxy-server conf value that allows
control of how many nodes are contacted for a normal request.
In proxy.controllers.base.Controller:
* Got rid of error_increment since it was only used in one spot by
another method and just served to confuse.
* Made error_occurred also log the device name.
* Made error_limit require an error message and also documented a bit
better.
* Changed iter_nodes to just take a ring and a partition and yield
all the nodes itself so it could control the number of nodes used
in a given request. Also happens to consolidate where sort_nodes is
called.
* Updated account_info and container_info to use all nodes from
iter_nodes and to call error_occurred appropriately.
* Updated GETorHEAD_base to not track attempts on its own and just
stop when iter_nodes tells it to stop. Also, it doesn't take the
nodes to contact anymore; instead it takes the ring and gets the
nodes from iter_nodes itself.
Elsewhere:
* Ring now has a get_part method.
* Made changes to reflect all of the above.
Change-Id: I37f76c99286b6456311abf25167cd0485bfcafac
In trying to override the content-type for the convenience
call I broke COPYs and POSTs for SLO. yaaa...
Change-Id: Ifbcda6d2dd0ee43e43d62e58a90301e7afd05e27
- We allow all headers requested in preflight request. The CORS
specification does leave the door open for this, as mentioned in
http://www.w3.org/TR/cors/#resource-preflight-requests
Note: Since the list of headers can be unbounded
simply returning headers can be enough.
- This is a followup to review:
https://review.openstack.org/#/c/24415/.
- Fixes bug 1155034.
Change-Id: If7b8f2f3a581c5209892d1ccc9f06ddb8fac92dd
Folks have actually been asking for this. I think they're sending a
DELETE TempURL to someone way ahead of time and the someone issues it
when they're ready. Honestly, I'm not entirely sure of the use case,
but having the set of methods configurable wouldn't hurt.
Change-Id: Ibdb48f8a72077b045eeedddfae4c0a1f56098d7a
DLO is supposed to sleep 1 second per segment after 10 (default) initial
segments are loaded to prevent abuse of the system. Currently, if the user
did a range request to the 11th segment the 1 sec delay would start immediately
on the 11th segment because the skipped segments were counted as initial
segments. This path fixes that.
Change-Id: I53bbc24af54921ddc04d9cb3b704366b51b3f740
A new configuration parameter is added to /etc/swift/swift.conf
[swift-hash]
swift_hash_path_prefix = 'random unique string'
New installations are advised to set this parameter to a random secret,
which would not be disclosed ouside the organization.
The same secret needs to be used by all swift servers of the same cluster.
Existing installations should set this parameter to an empty string
(the default)
DocImpact
Fixes: Bug #1157454
Change-Id: I63b10d0b7d6dd3f74e0f10bb41b5f240fa03578a
Added 411 responses in bulk and slo when needed.
Make X-Static-Large-Object an illegal header with slo installed- somehow
that got lost with some refactor I did.
Change-Id: I986c1656658f874172860469624118cc63bff9bc
If X-Copy-From is a manifest object, it can be bigger than MAX_FILE_SIZE.
Currently this fails with 503. It should be 413.
Bug #1158279
Change-Id: I7ec16088046c84e42d5be9c865e1338eb07845b6
Using insensitive case could tolerate human error. For example,
user maybe set like this "operator_roles = Admin, swiftoperator"
- also fix a mistake in test, ['admin'] is correct value for roles, not
'admin' (it will be looped as ['a', 'd', 'm', 'i', 'n'])
- add test for insensitive cases
Fixes: bug #1013120
Change-Id: I56d71da8bc503e48e92dd743692ba6fc237f029e
We can set x-versions-location empty to remove this header in API, but
to keep consistent, we should allow x-remove-versions-location too. The
usage is post "x-remove-versions-locaion: x", just like ACL remove
headers.
Fixed: bug #1107592
Change-Id: I1271eec6401d4a0e8c1a7c2d63aeb8dfef00bf6d
If you run list_parts against a builder that has never been
rebalanced, you'd get a crash. Now you don't.
To reproduce:
$ swift-ring-builder foo.builder create 8 3 1
$ swift-ring-builder foo.builder add r1z1-1.2.3.4:6000/sda 100
$ swift-ring-builder foo.builder list_parts z1
Change-Id: Ic3edffab0c5c2e9551a2f89ddb881153f0b07db7
The only place in the spec that I could see the Origin being checked was
during the pre-flight OPTIONS request. If it gets to the actual request
let auth decide. Please correct me if this is wrong.
Change-Id: Ic31b71746ec056091c7778ebff3db7becc32bd9c