When running e2e tests with a clouds.yaml that uses application credentials (rather than username/password), the generated cloud provider config for the workload cluster ends up with empty authentication fields. This causes the OpenStack Cloud Controller Manager to crash-loop, which blocks node initialization and cascades into scheduling failures for coredns, calico, etc.
The root cause is in test/e2e/shared/openstack.go — the AuthOpts struct and getEncodedOpenStackCloudProviderConf() function only map traditional username/password fields from clouds.yaml. If the cloud entry uses application_credential_id and application_credential_secret instead, those values are silently ignored, producing a cloud.conf with all auth fields blank.
The external OpenStack Cloud Controller Manager has supported application-credential-id and application-credential-secret in cloud.conf for a long time. Application credentials are also generally preferred over full user credentials since they follow least-privilege principles and are scoped to a single project.
Proposed fix:
Add application-credential-id and application-credential-secret fields to the AuthOpts struct and map them from the parsed clouds.yaml in getEncodedOpenStackCloudProviderConf().
/kind bug
When running e2e tests with a
clouds.yamlthat uses application credentials (rather than username/password), the generated cloud provider config for the workload cluster ends up with empty authentication fields. This causes the OpenStack Cloud Controller Manager to crash-loop, which blocks node initialization and cascades into scheduling failures for coredns, calico, etc.The root cause is in
test/e2e/shared/openstack.go— theAuthOptsstruct andgetEncodedOpenStackCloudProviderConf()function only map traditional username/password fields fromclouds.yaml. If the cloud entry usesapplication_credential_idandapplication_credential_secretinstead, those values are silently ignored, producing acloud.confwith all auth fields blank.The external OpenStack Cloud Controller Manager has supported
application-credential-idandapplication-credential-secretincloud.conffor a long time. Application credentials are also generally preferred over full user credentials since they follow least-privilege principles and are scoped to a single project.Proposed fix:
Add
application-credential-idandapplication-credential-secretfields to theAuthOptsstruct and map them from the parsedclouds.yamlingetEncodedOpenStackCloudProviderConf()./kind bug