You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When deploying the management plane in GCP, there is a bit of flexibility when configuring the FQDN. Users can create a FQDN with the .private suffix to create an internal zone, and can use any other name that is not the gcp.cx.tetrate.info and a public DNS zone will be created.
However, that zone needs to be explicitly configured so that other projects (and clusters can see it), and this is something that needs to be done beforehand, by pointing the Domain to the nameservers in that zone. This breaks the CP deployment in GCP if using this approach.
In order to fix it, public zones should be assumed to exist (like we do with the shared one) instead of being created, and the project in which they exist should be configurable.
This is a small change I already fixed in my fork (last 3 files of this commit): nacx@bf8b200
The text was updated successfully, but these errors were encountered:
When deploying the management plane in GCP, there is a bit of flexibility when configuring the FQDN. Users can create a FQDN with the
.private
suffix to create an internal zone, and can use any other name that is not thegcp.cx.tetrate.info
and a public DNS zone will be created.However, that zone needs to be explicitly configured so that other projects (and clusters can see it), and this is something that needs to be done beforehand, by pointing the Domain to the nameservers in that zone. This breaks the CP deployment in GCP if using this approach.
In order to fix it, public zones should be assumed to exist (like we do with the shared one) instead of being created, and the project in which they exist should be configurable.
This is a small change I already fixed in my fork (last 3 files of this commit): nacx@bf8b200
The text was updated successfully, but these errors were encountered: