Kill off 'DEFAULT_TOPIC_NAME'.

[tseaver]

The hypothesis is that we are seeing flakiness due to rapid creation / deletion cycles on topics with the shared name.

Towards #2163, #2192.

[tseaver]

@dhermes, @daspecster I'm tempted to kill off the Travis for the PR and merge immediately: the system tests pass with this change on my box, and tox -e lint is happy. Since the only point of it is to try to fix post-PR builds, I'd like to know whether it works. :)

[dhermes]

The resource ID has per-second granularity on Travis. You probably want to go lower by a factor of 100. Add an optional argument to multiply seconds in time.time() before casting to an int?

[dhermes]

@tseaver I urge you to resist the temptation. Travis won't run your job for hours so it's not worth subverting the review process

[dhermes]

I just read the definition of "subvert". A very dramatic word

[tseaver]

The resource ID has per-second granularity on Travis. You probably want to go lower by a factor of 100. Add an optional argument to multiply seconds in time.time() before casting to an int?

We're already mangling in the TRAVIS_BUILD_ID into the unique_resource_id return value on Travis: are you worried we will be running two jobs with the same ID? The theory here is that reusing a topic ID within one run is the source of the flakiness we are seeing in #2163 and #2192.

Travis won't run your job for hours so it's not worth subverting the review process

That means it will be double that number of hours before we know whether it works.

[dhermes]

Sorry I didn't realize your prefixes were unique, so it's moot.

LGTM to merge (no need to wait on Travis if you've run all the tox environmentsvthst Travis will)

[dhermes]

*environments that (typing on phone, sorry)

[tseaver]

Fingers crossed

[tseaver]

W00t! the remaining failures are due to #2176.