-
Notifications
You must be signed in to change notification settings - Fork 218
chore: refactor InstanceAdditionalDiskSpec for reuse in MachinePool #1507
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: refactor InstanceAdditionalDiskSpec for reuse in MachinePool #1507
Conversation
✅ Deploy Preview for kubernetes-sigs-cluster-api-gcp ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
dd13c9c
to
6ad6bb0
Compare
This will avoid code duplication in MachinePool (#1506) An alternative approach to the long-list of parameters would be to define a struct, which would effectively give us named arguments, so something like this:
I think that's not worth it because the arguments are already relatively self documenting, but happy to switch if people would prefer that. |
Should I tweak apidiff to ignore our internal functions? I consider cluster-api-provider-gcp as a leaf, so I don't think we really want apidiff except on our CRDs? |
/retest |
@justinsb: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
/lgtm |
@bochengchu: changing LGTM is restricted to collaborators In response to this:
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. |
@@ -12,6 +13,8 @@ import ( | |||
// This test verifies that if a user selects "local-ssd" | |||
// as a disk type then the MachineScope correctly detects it as such. | |||
func TestMachineLocalSSDDiskType(t *testing.T) { | |||
ctx := context.Background() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we use the T.Context() here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh wow! I have been wanting this for a long time. I had missed that it was introduced - but it was introduced in 1.24.
I think we're pinned to go 1.23 in go.mod, but it gets auto-bumped if we move to CAPI 1.11 (#1509)
We can also bump the go toolchain in go.mod - do we want to do that?
(I totally agree that when we bump to go 1.24 we should use T.Context here and probably in many other places!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree let's defer that after we get CAPI 1.11 and go 1.24 in
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A clarification question: Is there any impact on the existing running clusters? When the user upgrades to a version that has this change
Not sure if you mean this PR - this PR is a mechanical function extraction to make #1506 a little shorter and easier to review. It should behave 100% identically unless I screwed up (which is not unlikely, but my intent is no observable external change) If you mean #1509 - the CAPI upgrade - I am indeed trying to do that without breaking changes. AIUI capi 1.11 does not remove v1beta1, but adds v1beta2. We are encouraged to move our own APIs to v1beta2 conventions, but I have not done that yet. The intent of #1509 is just to add support for the new libraries / new versions. But that upgrade is much riskier so I would like to follow whatever branching policy we're using before merging that one. |
I agree, I think at first we can bump to CAPI v1.11 and keep us on v1beta1, and then consider jumping on v1beta2 as a follow up or in a follow up minor release. |
6ad6bb0
to
43876e5
Compare
Trying to track down why that apidiff job is hanging ... hopefully it is just a networking flake pulling go dependencies, so I have proposed a timeout in kubernetes/test-infra#35469 (and thank you @damdo for approving that!). But of course I did touch this recently, so it may need a deeper fix ... TBD Assuming I can get that test passing, I think that this one should not block on the CAPI update (and thus nor should it block on T.Context), because it is in support of MachinePool, not the CAPI upgrade. I am assuming we will support MachinePool before CAPI 1.11, because they are logically separate, but happy to discuss that assumption: I'd rather get MachinePool in sooner, but it also looks like we can bump to CAPI 1.11 without too much trouble (I'm working on that PR next!) |
This is preparing for reuse in MachinePool.
43876e5
to
e6b73ee
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this is a pre-factor right?
/approve
/lgtm
/hold
Feel free to unhold when ready to merge it
@@ -12,6 +13,8 @@ import ( | |||
// This test verifies that if a user selects "local-ssd" | |||
// as a disk type then the MachineScope correctly detects it as such. | |||
func TestMachineLocalSSDDiskType(t *testing.T) { | |||
ctx := context.Background() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree let's defer that after we get CAPI 1.11 and go 1.24 in
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: damdo, justinsb The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Exactly! I can continue to do these to break down #1506 to make it smaller as needed. I love "pre-factor", I hadn't heard that and will start using that term... I think it's ready! /hold cancel |
Uh oh!
There was an error while loading. Please reload this page.