-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Fixes 2932: let the capi version to be discovered #2934
Conversation
/hold cancel |
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.
Codewise looks good, just wondering whether we want to be calling all the variables etc Machine API or Cluster API, do we have a preference?
agreed, i think if we can use "cluster api" here it will reduce any confusion for someone reading this. at the very least we should name the external bits (eg env variable) to reflect cluster api. |
|
||
machineSetResource, _ := schema.ParseResourceArg(fmt.Sprintf("machinesets.%v", defaultMachineAPI)) | ||
machineSetResource, _ := schema.ParseResourceArg(fmt.Sprintf("machinesets.%v", specifiedMachineAPI)) | ||
if machineSetResource == nil { | ||
panic("MachineSetResource") |
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.
This should really return an error.
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.
mm why? atm MachineDeployment
, MachineSets and
Machine` are intentionally assumed to exist so it seems reasonable to me to panic 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.
Because it makes unit tests easier to write and assert for expected behaviour.
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.
ok make sense, let's address this separately from this PR. I'll move the capi resource expectations into its own unit tested func
which errors and let the caller panic.
cluster-autoscaler/cloudprovider/clusterapi/clusterapi_controller_test.go
Outdated
Show resolved
Hide resolved
cluster-autoscaler/cloudprovider/clusterapi/clusterapi_controller_test.go
Show resolved
Hide resolved
2f20344
to
223ef38
Compare
I renamed to CAPI consistently and moved code to fetch the preferred version into unit tested |
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.
in general it looks good to me, deduplicating the tests seems like a good idea.
Addressed comments and meld into one commit. PTAL @elmiko @frobware @JoelSpeed |
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.
/lgtm
cluster-autoscaler/cloudprovider/clusterapi/clusterapi_controller_test.go
Outdated
Show resolved
Hide resolved
cluster-autoscaler/cloudprovider/clusterapi/clusterapi_controller.go
Outdated
Show resolved
Hide resolved
cluster-autoscaler/cloudprovider/clusterapi/clusterapi_controller_test.go
Outdated
Show resolved
Hide resolved
…API version. This change adds detection for an environment variable to specify the group for the clusterapi resources. If the environment variable `CAPI_GROUP` is specified, then it will be used instead of the default. This also decouples the API group from the version and let the latter to be discovered dynamically.
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.
The issue (#2934) talks about discovering the version but, unless I'm mistaken, this only allows the group to be overridden. True?
This PR enables an env variable to override the default CAPI group and discovers the API version (#2932) see https://github.com/kubernetes/autoscaler/pull/2934/files#diff-89363471d762322b93c9bcfec57b5af8R302. Let me update the PR desc with the commit message. |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: frobware 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 |
/area provider/cluster-api |
/lgtm |
[CA-1.18] #2934 cherry-pick: Fixes 2932: let the capi version to be discovered
Add the ability to override CAPI group via env variable and discovers the API version.
This change adds detection for an environment variable to specify the group for the clusterapi resources. If the environment variable
CAPI_GROUP
is specified, then it will be used instead of the default. This also decouples the API group from the version and let the latter to be discovered dynamically.Fixes #2932