Shared VPC: editIgnition uses NetworkProjectID to fetch Compute Addresses, causing failures when addresses live in Service Project

[jamesregis]

Description

When installing OpenShift on GCP using Shared VPC + BYO subnets with UserProvisionedDNS enabled, the installer may fail while editing Ignition files due to incorrect project selection when retrieving Compute Addresses.

Context

• OpenShift version: 4.20

• Platform: GCP

• Installation type: IPI

• Network model: Shared VPC

  • Host project: contains VPC and subnets (networkProjectID)

  • Service project: contains cluster resources (projectID)

• DNS mode: UserProvisionedDNS enabled

Observed behavior

In editIgnition, the code determines the project used to fetch Compute Addresses as follows:

project := in.InstallConfig.Config.GCP.ProjectID
if in.InstallConfig.Config.GCP.NetworkProjectID != "" {
    project = in.InstallConfig.Config.GCP.NetworkProjectID
}

in pkg/infrastructure/gcp/clusterapi/ignition.go

This project value is then used for:

• svc.Addresses.Get(...) (regional addresses)
• svc.GlobalAddresses.Get(...) (global addresses)

In a Shared VPC setup, this causes issues when:

• the network and subnets are in the host project
• but the Compute Addresses (API / API-Int) are created in the service project

As a result, the installer attempts to retrieve addresses from the wrong project, leading to errors such as:

• 404 Not Found
• or 403 Forbidden

Why this is problematic

In Shared VPC architectures, it is common (and valid) for:

• networks/subnets to live in the host project
• Compute Addresses and load balancers to live in the service project

The current logic assumes that if NetworkProjectID is set, all related resources (including addresses) must exist in that project, which is not always true.

Expected behavior

One of the following approaches would be more robust:

1. Always retrieve Compute Addresses from ProjectID (service project), regardless of NetworkProjectID
2. Attempt lookup in ProjectID first, then fallback to NetworkProjectID
3. Derive the project directly from the address selfLink, instead of assuming it

Additional note

The code also dereferences the following fields without nil checks:

*gcpCluster.Status.Network.APIInternalAddress
*gcpCluster.Status.Network.APIServerAddress

This could cause a panic if these fields are not yet populated.

Impact

This issue blocks successful IPI installations on GCP using:

• Shared VPC
• BYO subnets
• UserProvisionedDNS

unless the environment happens to place Compute Addresses in the host project, which is not guaranteed.