Configuring region for Regional Backend config may be unnecessary and confusing
rwkarg opened this issue · 4 comments
I missed this when looking at #34 but I don't think there's any opportunity to make choices for the backend region.
An Internal HTTP LB (regional backend service) can only include Backends from the same region. So a Backend Service in us-west1 can only have Backends also in us-west1. Trying to configure autoneg on a us-west1 cluster to add instances to a us-east1 Backend Service will not work, I believe.
I addressed this by pulling the cluster location (region) from metadata: http://metadata.google.internal/computeMetadata/v1/instance/attributes/cluster-location so that user's aren't in the position of needing to magically know the only value that will actually work for region and having to explicitly configure it for each annotation.
One thing that may make this configuration required would be if there's potential for an Internal HTTP LB at some point in the future to allow Backends to be added to a Backend Service in a different region. If that happens, the it would become necessary to specify the Backend Service region in the annotation.
Fair point, I guess we could use region:"auto" or similar for that functionality.
Is there a case where we would want more than regional:true? Or can we think of any upcoming case?
With the current functionality of global and regional backend services, just a regional: true setting is all that is needed.
I know there is an expressed desire for Internal HTTP Load Balancers to allow for global access, similar to how Internal TCP/UDP Load Balancers can be configured for global/cross-region access today. But I don’t know if that is being worked on or if whenever something like that got it mplemented would still restrict backends to a single region or expand that out.
We can add support for regional boolean in addition to specifying the region manually. No harm in having both options.