test_ratelimit_max_rate_multiple_acc in unit.common.middleware.test_ratelimit.TestRateLimit failed in a verify gate check

[clayg]

Seen here:

http://logs.openstack.org/16/66916/1/gate/gate-swift-python26/43e45cd/console.html

Just need to evaluate and track.

[Alistair Coles (alistair-coles)]

Seen here:
http://logs.openstack.org/75/219775/1/gate/gate-swift-python27/913613d/console.html

[paul luse (paul-e-luse)]

acoles/clayg: FYI Siva is one of the Intel guys coming on board to work on Swift as part of the Intel/Rax thing aka OpenStack Innovation Center (OSIC).

On this one, I'm pretty sure I've seen this failure pattern a few times in the past and I think one or both of you have fixed stuff like this. Can anyone remember one to point Siva to one of those fixes to see if there is a general fix pattern as well for crap where we take a timestamp, do some shit, take another and then compare only to find out that this doesn't always work in the gate test env for whatever reason (and I cant remember why)?

[clayg (clay-gerrard)]

why: because sometimes something that should be quick on most computers is slow in the gate (because cloud vms sometimes pause for reasons completely undetectable from inside the virtualization sandbox).

The "solutions" come in one of two forms:

1) increase the tolerable variance in the assert (which typically decrease the ability of the test to find regressions from an inadvertently behavior change)

2) change the nature of the test to validate logic instead of behaviors by mocking the timing calls with real values to remove actual time from being an input (which typically decreases the ability of the test to be robust against implementation changes that do not change behavior)

e.g. maybe this change -> https://review.openstack.org/#/c/83277/

[paul luse (paul-e-luse)]

thanks Clay!!

[clayg (clay-gerrard)]

here -> http://logs.openstack.org/50/273850/4/check/gate-swift-python27/606a1c6/console.html