k8s-ci-robot
commented
2 months ago 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
Open lentzi90 opened 2 months ago
k8s-ci-robot
commented
2 months ago 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
commented
2 months ago [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.
netlify[bot]
commented
2 months ago | 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
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago 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
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:
TODOs:
/hold