Open Stack

On 08/03/2016 12:26 PM, Lance Bragstad wrote:
> Sending a follow-up because I think we ended up finding something
> relevant to this discussion.
> 
> As keystone moves towards making fernet the default, one of our work
> items was to mock the system clock in tests. This allows us to advance
> the clock by one second where we need to avoid sub-second race
> conditions. To do this we used freezegun [0]. We recently landed a bunch
> of fixes to do this.
> 
> It turns out that there is a possible race between when freezegun
> patches it's modules and when the test runs. This turned up in a patch I
> was working on locally and I noticed certain clock operations weren't
> using the fake time object from freezegun. As a work-around, we can
> leverage the set_time_override() method from oslo_utils.timeutils to
> make sure we are using the fake time from within the frozen time
> context. In my testing locally this worked.
> 
> If keystone requires a hybrid approach to patching
> (oslo_utils.timeutils.set_time_override() + freezegun), we should build
> it into a well documented hybrid context manager so that's its more
> apparent why we need it.
> 
> Sean, I can start working on this to see if it starts mitigating the
> races you're seeing.
> 
> [0] https://pypi.python.org/pypi/freezegun

Lance, thanks for digging into this! I think using the oslo
set_time_override sounds like the best approach, that's what I remember
other places to test time boundaries like this.

	-Sean

-- 
Sean Dague
http://dague.net