✨ Add NamePrefix field to OpenStackMachine.Spec

[lentzi90]

trafficstars

What this PR does / why we need it:

This adds a new field to the spec of OpenStackMachines: namePrefix. It is an optional field that can be specified as a way to influence how OpenStack resources are named. If it is not specified, the OpenStackMachine name will be used (current behavior).

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 #2039, related to https://github.com/kubernetes-sigs/cluster-api/issues/10463.

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:

• [x] squashed commits
• if necessary:
  • [ ] includes documentation
  • [x] adds unit tests

/hold

[k8s-ci-robot]

Skipping CI for Draft Pull Request. If you want CI signal for your change, please convert it to an actual PR. You can still manually trigger a test run with /test all

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please ask for approval from lentzi90. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[netlify[bot]]

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

Name	Link
🔨 Latest commit	8ce811693bb6c1c7f029cd3fca80c188d6ebefa1
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-sigs-cluster-api-openstack/deploys/662ba33330a00f00085446a7
😎 Deploy Preview	https://deploy-preview-2035--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 site configuration.

[mdbooth]

Unfortunately I don't have time to go into this deeply today, but my first impression is that I'm not keen.

It's worth noting that I'm generally supportive of the new CAPI default. It has always been a trip hazard that the Machine and InfraMachine have different names, and making them the same should be simpler for most people.

However, as you point out in the CAPI issue, it has been this way long enough that I think it's reasonable to treat it like a breaking change in practise, regardless of whether it was documented. I hope we can work with the CAPI folks to sort that out.

That said, this change would introduce that same trip hazard in CAPO, just moved one level down. The idea that cloud resources are named after the OpenStackMachine which owns them is simple and elegant. I'm not keen to break it, especially now that we've released v1beta1 and would be left supporting it indefinitely.

My strong preference is to work with CAPI to enable backwards-compatibility for the inadvertent breakage. I took a brief look and the code to support the previous behaviour is still there. I think this can and should be implemented by adding a backwards-compatibility flag (optional, defaults to the new behaviour) to CAPI.

[lentzi90]

Thank you for the comment @mdbooth ! I was reluctant to push this to begin with. Now I have a better understanding of the issue and the use-case. Based on that I have created https://github.com/kubernetes-sigs/cluster-api-provider-openstack/issues/2039. It is unfortunately a feature that we really need. We just didn't realize until the breaking change in CAPI.

Could you please take a look at the issue and see if this makes sense to you? I'm very open to suggestions for how exactly we should implement this!

[mdbooth]

It looks like you're making good progress in https://github.com/kubernetes-sigs/cluster-api/pull/10511. I think this PR would be redundant if we're successful getting this fixed in CAPI.

Can we hold fire on this to see how that goes? I'd very much prefer to see this fixed in CAPI rather than carry our own custom workaround.

[lentzi90]

Sure, there is no hurry with this. However, https://github.com/kubernetes-sigs/cluster-api/pull/10511 will only provide a temporary solution. It is targeting only the release branch and will be gone by CAPI v1.8

[k8s-ci-robot]

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[lentzi90]

This is not needed. There is work on-going for a long term fix in CAPI.