Imagine I have a VPC called vpc-1 which has a Memorystore (Redis) instance associated with it. My understanding is that Redis lives in its own VPC and there is VPC peering used to connect vpc-1 to the VPC for Redis. Now let us imagine I create a second VPC called vpc-2 and peer that VPC with vpc-1. I now create a VM with a network interface to vpc-2. This VM can now access VPC resources attached to vpc-1 and vpc-2. However, because VPC peering is not transitive, the VM can't access the Redis instance.
My puzzle now becomes one of ... is it possible for a VM attached to vpc-2 that is VPC peered to vpc-1 which has a Memorystore (Redis) instances associated with it (vpc-1) to access that Redis instance?
I realize that I can switch my story to use Shared VPC ... however I'm wondering what options exist if I want to use VPC Peering exclusively.
After discussions with technical folks who know GCP VPC and GCP Memorystore very well, it seems that there is no way to have transitive peering using VPC Peering. A solution was suggested that, for my use case, worked well. With respect to the original story, we created a new Compute Engine in the vpc-1 VPC which has access to Redis. On that Compute Engine we installed the open source package called nutcracker which provides a Redis proxy. What this means is that a Redis client request sent to this Compute Engine is proxied to the real Redis server managed by Google through Memorystore. Since the Compute Engine is an ordinary compute resource in the vpc-1 VPC its internal IP address is reachable from other VPCs peered with vpc-1 (for example, in our story vpc-2). The end result was that a Compute Engine created in vpc-2 could then target the Compute Engine running nutcracker using the Redis protocols. That Compute Engine then relayed the request to the real Redis server and all worked as desired.