🌱 Add OpenStackAuthenticationSucceeded condition

[lentzi90]

What this PR does / why we need it:

• Sets OpenStackAuthenticationSucceededCondition to True/False based on credential validity during reconciliation.
• Adds tests for condition handling on credential errors and missing secrets.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #2264

Special notes for your reviewer:

1. Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

TODOs:

• squashed commits
• if necessary:
  • includes documentation
  • adds unit tests

/hold

[netlify]

✅ Deploy Preview for kubernetes-sigs-cluster-api-openstack ready!

Name	Link
🔨 Latest commit	36e4343
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-sigs-cluster-api-openstack/deploys/697cae125ec5ec0008ca0df9
😎 Deploy Preview	https://deploy-preview-2985--kubernetes-sigs-cluster-api-openstack.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[lentzi90]

Maybe a better name would be OpenStackCredentialsExists?

[nikParasyr]

Maybe a better name would be OpenStackCredentialsExists?

I do indeed think that OpenStackCredentialsReadyCondition means more that the credentials are there and valid.
So i'd prefer a better name, not sure which one myself:

• OpenStackCredentialsExists: a bit better but dont like the exists part that much
• OpenStackCredentialsResolved: sort of the same, still not like the resolved
• OpenStackCredentialsAvailable: i think this is a bit clearer

[lentzi90]

OpenStackCredentialsAvailable: i think this is a bit clearer

I like this also! Changing :)

[lentzi90]

/hold cancel

[lentzi90]

/cc @mandre @bnallapeta

[nikParasyr]

/lgtm

[mandre]

Should we try to define a condition that is perhaps a little bit less specific?
From a user point of view, I'd like to know that something is wrong with the credentials without having to look at the logs, as it was captured in the referenced issue. I'd like this condition to points me to the right direction for debugging the issue. That "something is wrong" might not just be "there's no credentials at all" but also "the creds are wrong" or "the clouds.yaml doesn't have the necessary data".

Do you think a more generic condition like OpenStackAuthError better captures it?

[mandre]

Obviously, if we're using a condition that express "I can't connect to the cloud", we would need to change its status in more places.

[lentzi90]

Hmm, yes it would be good to capture more issues, but I am not sure how much more we can do at this early stage. If the secret is missing or malformed, we get a reconciliation error here. Those errors are included in the message with the condition, so the user do get that information.

When there are issues later on, it is usually quite hard to know if they are related to the credentials without parsing the error messages. I am hoping that we do set relevant conditions and messages in most places though.
Checking for the very first time we try the API, I think it is

cluster-api-provider-openstack/controllers/openstackcluster_controller.go

Lines 330 to 333 in 9e848d9

	err = reconcileNetworkComponents(scope, cluster, openStackCluster)
	if err != nil {
	return reconcile.Result{}, err
	}

Sigh... we set no condition.
I'll add something here also and test this locally.

[lentzi90]

Documenting findings from manual tests. I was wrong about how far we check the credentials when creating the scope. We do notice all kinds of issues here immediately, so that is really great. I'll still create an issue for adding a condition to that reconcileNetworkComponents error...

@mandre what do you think about these below? Are they good enough (at least as a first step)?

Here is the condition for a cluster with non-existing credentials secret:

status:
  conditions:
  - lastTransitionTime: "2026-01-29T11:05:25Z"
    message: 'Failed to create OpenStack client scope: secrets "dev-test-cloud-config"
      not found'
    reason: OpenStackCredentialsFailed
    severity: Error
    status: "False"
    type: OpenStackCredentialsAvailable
  ready: false

This I am quite happy with. It clearly shows which secret it is unhappy about and why. "OpenStack client scope" is perhaps not immediately understandable, but it avoids making assumptions about the kind of error we get. We cannot know if there is some parsing error or something else entirely going on so I think it is quite ok.

Next, I created a secret with matching name but nonsense content. Then I got this:

status:
  conditions:
  - lastTransitionTime: "2026-01-29T11:12:59Z"
    message: 'Failed to create OpenStack client scope: OpenStack credentials secret
      dev-test-cloud-config did not contain key clouds.yaml'
    reason: OpenStackCredentialsFailed
    severity: Error
    status: "False"
    type: OpenStackCredentialsAvailable
  ready: false

This is also really nice IMO!

Then I did one with proper content but wrong clouds:

spec:
  identityRef:
    cloudName: capo-e2e # <-- This does not exist in the clouds.yaml
    name: dev-test-cloud-config
    type: Secret
...
status:
  conditions:
  - lastTransitionTime: "2026-01-29T11:16:19Z"
    message: 'Failed to create OpenStack client scope: auth option failed for cloud
      : Missing input for argument [auth_url]'
    reason: OpenStackCredentialsFailed
    severity: Error
    status: "False"
    type: OpenStackCredentialsAvailable
  ready: false

It is looking for capo-e2e but it doesn't exist. Not the best error message, but I am not sure how to improve. Should we add extra validation somewhere? I think this is coming from gophercloud currently.

Next, correct cloud entry except the password was wrong:

status:
  conditions:
  - lastTransitionTime: "2026-01-29T11:21:47Z"
    message: 'Failed to create OpenStack client scope: providerClient authentication
      err: Expected HTTP response code [201 202] when accessing [POST http://10.0.3.15/identity/v3/auth/tokens],
      but got 401 instead: {"error":{"code":401,"message":"The request you have made
      requires authentication.","title":"Unauthorized"}}'
    reason: OpenStackCredentialsFailed
    severity: Error
    status: "False"
    type: OpenStackCredentialsAvailable
  ready: false

Quite ok I would say.

Finally, wrong URL:

status:
  conditions:
  - lastTransitionTime: "2026-01-29T11:23:19Z"
    message: 'Failed to create OpenStack client scope: providerClient authentication
      err: Get "http://10.0.3.150/identity/": EOF'
    reason: OpenStackCredentialsFailed
    severity: Error
    status: "False"
    type: OpenStackCredentialsAvailable
  ready: false

Also ok IMO.

All in all, I think this is a clear improvement. Before this PR we did not get any conditions at all. Users had to dig through logs.

[mandre]

Thanks for manually checking the different cases. I believe this covers the most important ones indeed.

I'd still rename the condition to OpenStackAuthenticationSucceded or something equivalent now that we confirmed it's set to false in more cases than just missing secrets.

[lentzi90]

Good point! I guess there is a little risk that authentication fails later, in the middle of operations. Then we probably would not be able to set this condition. But the next reconcile should handle that anyway so should be fine.
I'll update the name.

I also realized now that we should check all other controllers and see if we can do the same there. This one is the most critical, but we could have different credentials per OpenStackMachine and those should also have conditions then.

[lentzi90]

/hold
TODO: I should check if I can remove the //nolint comments now after renaming...

[bnallapeta]

@lentzi90 please update once this is ready for review. Thanks.

[lentzi90]

/hold cancel
Now this is up to date and all changes done. PTAL! 🙂

[lentzi90]

I forgot to mention that I didn't include OpenStackMachineTemplate here. It has no conditions at all yet and I didn't want to "mess with the API" just to add these conditions there also. I'll instead do a follow up PR where I add conditions there.

[mandre]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mandre

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [mandre]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[bnallapeta]

Looks good in general. Pending those minor comments.

[lentzi90]

Thanks @bnallapeta ! Good findings!

[bnallapeta]

/lgtm