The bulk of this change is the introduction of a GcpResource object to
track the created VMs, backend services, URL maps, etc. The additional
test cases for xDS integration greatly increase the complexity of the
resources required (e.g., multiple backend services, instance groups in
different zones) and the GcpResource construct makes keeping track of -
and cleaning up - these resources much cleaner.
--service_port_range replaces --grpc_port and allows the test driver to
pick an available port, allowing multiple instances of the test to run
simultaneously in the same GCP project and network
I discovered a couple of existing shortcomings while implementing this
client that mean this is *not yet ready for inclusion in CI*. I
nonetheless want to get an early review and integrate this to the master
branch, in the interest of small easily reviewable code changes.
The first problem was that the bazel build has apparently never pulled
roots.pem in as a data dependency. This appears not to have been a
problem until XDS enters into the mix. This has been added into the
Bazel build with a small change to the pyx_library rule.
The larger problem is that there is currently no public Python API to
get a peer's identity from the client side. This is crucial to
determining the correctness of an interaction of a client-server pair
under XDS. I intend to add such an method to the RpcContext interface in
an upcoming PR and use it in the interop client. For the moment, I
simply fake the peer details.
Finally, I add a knob to run_xds_tests.py allowing multiple instances of
this test to exist at once. Multiple instances forwarding to the same
port cannot exist on GCE, so this enables multiple people to run tests
at the same time.