Avoid sharing database name between testcase classes.

[tseaver]

Abrupt shutdown (maybe CircleCI auto-cancellation?) can cause them not to be cleaned up.

[dhermes]

This tries to address some recent failures:

• https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/3935
• https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/3929
• https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/3923
• https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/3911
• https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/3898
• https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/3891
• https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/3887
• https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/3884
• https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/3880
• https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/3877

@tseaver Has also "cleaned" up recent sessions by hand.

I also pushed this branch to the GoogleCloudPlatform remote so we can see the system tests build go green.

[dhermes]

@tseaver These tests end up with a 409 Conflict. We'll pick this back up tomorrow?

[dhermes]

Based on the success of

• https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/3952
• https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/3953

it's clear that

• the failures were caused by a failed clean-up of old tests
• this fix is still insufficient, since the 409 was caused when this build ran at the same time as another

[tseaver]

The "obvious" fix would be to use a per-CI-run instance (using our normal unique_resource_id() helper, which is what we did prior to #3951. However, the Spanner folks throttle us at a maximum of 3 instances, and we have to keep one (gcp-streaming-systests) around, pre-populated. That means that even if we mangle the instance name, and never screw up the cleanup, we can have at most two CI runs happening at one time.

We could try mangling the database names, rather than the instance name: it is possible that we wouldn't hit a different quota limit for databases-within-an-instance.

[dhermes]

@tseaver Could we check if it exists before using it in a class setup, then sleep (or fail the test) if it already exists?

[tseaver]

@lukesneeringer Or we could ask again to get our quota raised: they acted like it was impossible back before I capitulated and put in #3951.

[tseaver]

@dhermes We really don't want to share the database between test runs: they could step on each other in lots of ways beyond the creation bit.

[tseaver]

@dhermes https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/3964 is the run which will actually exercise the system tests from 2a66746.

[dhermes]

We really don't want to share the database between test runs: they could step on each other in lots of ways beyond the creation bit.

I wasn't suggesting we do. I was suggesting we either

• wait until the class knows it has created the database
• give up if the database already exists (would need to use unittest.TestCase.skipTest at run time vs. unittest.skipIf at import time)

[dhermes]

@tseaver You should rebase this PR so that your "Declare target packages (changed packages and dependencies)." doesn't end up with packages you don't care about.

[tseaver]

I'm not sure I get why the rebase, but I've done it blindly.

[dhermes]

@tseaver If you'd like to understand how "Declare Target Packages" works:

• https://github.com/GoogleCloudPlatform/google-cloud-python/blob/185c585bcbaaf307e2ef62c265eda49c41808b4f/.circleci/config.yml#L38-L42
• https://github.com/GoogleCloudPlatform/google-cloud-python/blob/185c585bcbaaf307e2ef62c265eda49c41808b4f/test_utils/scripts/get_target_packages.py

In particular, get_target_packages.py does a somewhat naive diff against master. So if your branch is behind master, you end up with a diff against HEAD vs. your merge base (this is actually the "right" idea). The files in the diff determine which packages get tested.

[tseaver]

The Appveyor varioure is the same (bogus) "invalid version number" error. Any other reason not to merge this?

[dhermes]

@tseaver If you rebase from master, it'll go away (I fixed in #4313).

[dhermes]

But go ahead and merge, no need to re-run tests.