The assumption that there may be only one rule per prefix has
been removed. The rules specifically tested here--without tag
filters--do overlap but are not in conflict.
I am proposing to remove altogether rather than writing new
deconfliction logic.
Signed-off-by: Matt Benjamin <mbenjamin@redhat.com>
Signed-off-by: Ali Maredia <amaredia@redhat.com>
since make_json_policy is redundantly doing most of the same work,
refactor to use the new policy classes instead
Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
- Improve `make_json_policy` to support conditionals in policy
- Move the helper functions for creating policies up so that bucket
policy tests can use these
- add bucket-policy attribute to the tagging tests using policy
Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
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>
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>
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>
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>
