]> git-server-git.apps.pok.os.sepia.ceph.com Git - s3-tests.git/commit
lc: Give more flexibility for LC expiration times 185/head
authorAbhishek Lekshmanan <abhishek@suse.com>
Thu, 7 Sep 2017 09:50:00 +0000 (11:50 +0200)
committerAbhishek Lekshmanan <abhishek@suse.com>
Thu, 7 Sep 2017 09:50:00 +0000 (11:50 +0200)
commit9204283def8e0bcfe14a57f0c87ed20735214f53
tree8d0e7fc8db781aefc706285cdddcf20e239ea18e
parent425d20998924ec2de96524276c55fb879187c16b
lc: Give more flexibility for LC expiration times

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>
s3tests/functional/test_s3.py