On Thu, Feb 10, 2022 at 12:35:24PM -0500, Casey Bodley wrote: > but if our goal was the minimize the runtime of these tests, i would > consider a model more like our https://github.com/ceph/ragweed/ tests, > where each test case is split up into a 'prepare' step and 'check' > step. we use ragweed in upgrade tests, which run the prepare step > against an older radosgw version, and the check step against an > upgraded radosgw +1 on this idea in general, as somebody who's had to poke lifecycle. > instead of relying on rgw_lc_debug_interval to scale the 'Days' in > lifecycle rules, 'radosgw-admin lc process' could take a new argument > like --rgw-lc-debug-offset=86400 that adds a day to the 'current' time > used in lifecycle time comparisons. without relying on sleeps and > rgw_lc_debug_interval, this should make the tests much more reliable. > if there are test cases that check progress over multiple expiration > cycles, the rgw/lifecycle suite would need to loop over more steps > instead of just prepare/check Rather than an offset, what about pinning the time that RGW thinks it is? That way we can upload objects as a known timestamp, and test at a variety of faked absolute future times, rather than relying on offset calculations. This is a reminder I also need to upstream the patch that lets each 'radosgw-admin lc process' call on just a single bucket (and then a specific shard in future). -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robbat2@xxxxxxxxxx GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
