For default-bucket and versioning-suspended-bucket, no version-id should return when upload.
For versioning-enabled-bucket, an non-empty version-id should return and equal to what
bucket list shows.
Signed-off-by: Xinying Song <songxinying@cloudin.cn>
(cherry picked from commit 9506ac220f)
Some tests, like test_object_header_acl_grants and
test_bucket_header_acl_grants, use the same id for all permissions.
Sort() is stable, so those tests end up testing the order of acl grants
returned by Boto. Not sure, but I think this may in turn depend on the
order of HTTP headers, where the order is not significant.
Signed-off-by: Tim Burke <tim.burke@gmail.com>
(cherry picked from commit 301272c0ef)
Added test cases for LC policies with no ID in xml, no prefix and an
empty and non empty Filter.
Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
(cherry picked from commit cc2d6f076f)
Earlier values expected a lc debug interval of 2s, which is a pretty
short time window and can often lead to failures if the processing
didn't complete within the next day. This commit assumes the currently
configured LC debug interval of 10s, and gives time intervals using the
following logic:
Worst case:
LC start-time : 00:00
obj upload : 00:01
LC run1 : 00:10 -> object not expired as it is only 9s old
LC run2 : 00:20 -> object will expire in this run, however we
can't exactly guess when this run will complete, for a moderate amount
of objects this can take anywhere between 1 to a max of 10s, let us give
it a wiggle room to complete around 8s, given the amount of objects in a
teuthology run, it should be mostly probable that the object is already
deleted within this time, so at 28s, we should have seen day1 objects being
expired.
Best case:
LC start-time: 00:00
obj upload : 00:09
LC run1 : 00:10
LC run2 : 00:20 -> obj expires, so elapsed time is around 11->19s (of
course it would almost close to 10s too), We should probably configure
the LC lock time to 10s as well just so as to ensure that the lock isn't
held for the default 60s in which case it is possible that the object
might expire in a time greater than the lock interval.
Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
(cherry picked from commit 9204283def)
Allows us to additionally filter out these tests which currently fail in
the teuthology runs
Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
(cherry picked from commit edeb956a82)
Encryption request headers should not be sent for GET requests and HEAD
requests if your object uses SSE-KMS/SSE-S3 or you’ll get an HTTP 400
BadRequest error.
Signed-off-by: hechuang <hechuang@xsky.com>
(cherry picked from commit 58944d0ba6)
- adds test for put obj with tagging query
- adds test for HEAD obj with x-amz-tagging-count verification
- adds test for put object tagging
- adds test for get object tagging
- adds test for post object tagging
- adds test for delete object tagging
- also verify& exceed the max tags
- add tagging condition to bucket acl
Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
According to https://tools.ietf.org/html/rfc7232
header 'If-Modified-Since' should be a correct HTTP-date.
For example: `Tue, 15 Nov 1994 12:45:26 GMT`;
not `1994-11-15T12:45:26.000Z`.
Signed-off-by: Evgenii Gorinov <korvin.lucky@gmail.com>
According to https://tools.ietf.org/html/rfc7232, If-Match field should looks like QUOTES ETag QUOTES.
Signed-off-by: Evgenii Gorinov <korvin.lucky@gmail.com>
