-
Notifications
You must be signed in to change notification settings - Fork 4.2k
read min and max values from nodepool tags for oci autodiscovery #8491
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
read min and max values from nodepool tags for oci autodiscovery #8491
Conversation
Hi @gvnc. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
/ok-to-test |
1f1b469
to
f8667aa
Compare
nodepool.minSize = nodeGroup.minSize | ||
nodepool.maxSize = nodeGroup.maxSize | ||
// set minSize-maxSize from nodepool free form tags, or else use nodeGroupAutoDiscovery configuration | ||
nodepool.minSize = getIntFromMap(nodePoolSummary.FreeformTags, "minSize", nodeGroup.minSize) |
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 declare "minSize" and "maxSize" as const variables?
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.
done.
|
||
nodepool.manager = nodeGroup.manager | ||
nodepool.kubeClient = nodeGroup.kubeClient | ||
|
||
m.staticNodePools[nodepool.id] = nodepool | ||
klog.V(5).Infof("auto discovered nodepool in compartment : %s , nodepoolid: %s", nodeGroup.compartmentId, nodepool.id) | ||
klog.V(4).Infof("auto discovered nodepool in compartment : %s , nodepoolid: %s ,minSize: %d, maxSize:%d", nodeGroup.compartmentId, nodepool.id, nodepool.minSize, nodepool.maxSize) |
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.
I think this is an important log, should we set this to default verbosity rather than 4?
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.
I agree the log is important, the only thing holding me back is that refresh cache mechanism is triggered too often and this log will become very noisy if we enable it by default.
@trungng92 Could you provide your feedback on this ?
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.
I think we should have a log this with default verbosity inside the the CreateNodePoolManager function after line 175, this way it isn't called after every referesh.
Something similar is done for the 'nodes' argument in line 284.
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.
And the log line within this function can remain with a lower verbosity.
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.
Something similar is done for the 'nodes' argument in line 284.
We already have an equivalent log for nodeGroupAutoDiscovery.
https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/oci/nodepools/oci_manager.go#L343
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.
If we move the log line to CreateNodepoolManager function as you suggested, it will be only printed once when the CA pod gets started, but it wouldn't show the latest list of nodepools. When customer updates the nodepool tags or adds a new nodepool that satisfies the discovery rules, we wouldn't see the updates.
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.
I am okay with having it log in the refresh loop as long as we are only logging newly discovered node pools (e.g. if we discover node pool 1 on iteration 1, and node pool 2 on iteration 2, only log node pool 2).
It would be nice to avoid logging all auto discovered node pools every time (although technically it may be useful in the edge case where the user removes an auto discovered tag from a node pool).
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.
I modified the code and added comparison logic to log the updates. It makes a copy of already discovered nodepools and runs a fresh auto-discovery, then it compares 2 lists and logs if there are any New/Updated/Deleted nodepools. Otherwise, it logs nothing.
I have also added a test method to validate the changes. See the logs from the test output below.
=== RUN TestNodeGroupAutoDiscovery
I0911 18:23:19.562355 71028 oci_manager.go:361] node group auto discovery spec constructed: &{manager:<nil> kubeClient:<nil> clusterId:ocid1.cluster.oc1.test-region.test compartmentId:ocid1.compartment.oc1.test-region.test tags:map[ca-managed:true namespace.foo:bar] minSize:1 maxSize:5}
I0911 18:23:19.564702 71028 oci_manager.go:434] Nodepool min/max sizes are updated. [id: node-pool-2 ,minSize: 4, maxSize:10]
I0911 18:23:19.564710 71028 oci_manager.go:432] New nodepool discovered. [id: node-pool-1 ,minSize: 1, maxSize:5]
I0911 18:23:19.564714 71028 oci_manager.go:441] Previously auto-discovered nodepool removed from the managed nodepool list. nodepoolid: node-pool-3
I0911 18:23:19.564717 71028 cache.go:44] rebuilding cache
I0911 18:23:19.564721 71028 oci_manager.go:452] Refreshed NodePool list, next refresh after 2025-09-11 18:28:19.56472 +0100 BST m=+300.032385626
I0911 18:23:19.564759 71028 cache.go:44] rebuilding cache
I0911 18:23:19.564761 71028 oci_manager.go:452] Refreshed NodePool list, next refresh after 2025-09-11 18:28:19.564761 +0100 BST m=+300.032426626
--- PASS: TestNodeGroupAutoDiscovery (0.00s)
PASS
LGTM |
933ada9
to
4dd21c3
Compare
3343152
to
e77e29c
Compare
/release-note-edit
|
@jackfrancis: /release-note-edit must be used with a release note block. 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. |
@jlamillan I'll happily merge this once you give an lgtm |
/lgtm |
/release-note-edit
|
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gvnc, jackfrancis 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 |
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR is to enhance the way node-group-auto-discovery parameter works.
node-group-auto-discovery parameter already accepts min/max values from the user but all the nodepools captured by discovery options will inherit the same min/max values and there is no way to set nodepool specific values.
With this change, users will be able to set nodepool specific min/max values by setting nodepool tags minSize and maxSize.
Lets suppose the cluster has 2 nodepools with the nodepool tags;
nodepool1 -> autoDiscover=true, minSize=2, maxSize=5
nodepool2 -> autoDiscover=true
And the node-group-auto-discovery parameter has values min:1, max:3. Then the nodepool sizes will be determined as;
nodepool1 -> min:2, max:5
nodepool2 -> min:1, max:3
Which issue(s) this PR fixes:
Special notes for your reviewer:
It was tested on OCI. The v=4 logs are as below.
Does this PR introduce a user-facing change?