[ML] Trained Model: Fix start deployment with ML autoscaling and 0 active nodes #201256
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
darnautov
added
Team:ML
darnautov
added
v8.18.0
v8.16.2
ci:cloud-deploy
|
Pinging @elastic/ml-ui (:ml) |
jgowdyelastic
approved these changes
Nov 22, 2024
| // If doesn't exist, then keep the false | ||
| // If ml autoscaling policy doesn't exist or the user does not have privileges to fetch it, | ||
| // check the number of lazy ml nodes to determine if autoscaling is enabled. | ||
| const lazyMlNodeCount = await getLazyMlNodeCount(client); |
There was a problem hiding this comment.
It seems like this check will always work and so we don't really need to attempt to fetch getAutoscalingPolicy as they'll produce the same results.
There was a problem hiding this comment.
there are cases when this check won't work, e.g.
- ML auto scaling may be disabled in the tier
- We’ve hit the autoscaling limit
- On prem users can set the settings, but it won't scale
So checking the autoscaling policy as a current user is still worth trying
|
@peteharverson the vCPU levels issues is fixed in 37ee935 |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Async chunks
History
cc @darnautov |
8 tasks
peteharverson
approved these changes
Nov 26, 2024
|
Starting backport for target branches: 8.16, 8.17, 8.x |
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Nov 26, 2024
…tive nodes (elastic#201256) ## Summary During my testing, I used the current user with all required privileges but failed to notice that, after switching to the internal` kibana_system` user, it lacked the manage_autoscaling privilege required for the `GET /_autoscaling/policy` API. As a result, the `isMlAutoscalingEnabled` flag, which we rely on in the Start Deployment modal, was always set to false. This caused a bug in scenarios with zero active ML nodes, where falling back to deriving available processors from ML limits was not possible. You can check the created deployment, it correctly identifies ML autoscaling: <img width="670" alt="image" src="https://github.com/user-attachments/assets/ff1f835e-2b90-4b73-bea8-a49da8846fbd"> Also fixes restoring vCPU levels from the API deployment params. ### Checklist Check the PR satisfies following conditions. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios (cherry picked from commit 9827a07)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Nov 26, 2024
…tive nodes (elastic#201256) ## Summary During my testing, I used the current user with all required privileges but failed to notice that, after switching to the internal` kibana_system` user, it lacked the manage_autoscaling privilege required for the `GET /_autoscaling/policy` API. As a result, the `isMlAutoscalingEnabled` flag, which we rely on in the Start Deployment modal, was always set to false. This caused a bug in scenarios with zero active ML nodes, where falling back to deriving available processors from ML limits was not possible. You can check the created deployment, it correctly identifies ML autoscaling: <img width="670" alt="image" src="https://github.com/user-attachments/assets/ff1f835e-2b90-4b73-bea8-a49da8846fbd"> Also fixes restoring vCPU levels from the API deployment params. ### Checklist Check the PR satisfies following conditions. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios (cherry picked from commit 9827a07)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Nov 26, 2024
…tive nodes (elastic#201256) ## Summary During my testing, I used the current user with all required privileges but failed to notice that, after switching to the internal` kibana_system` user, it lacked the manage_autoscaling privilege required for the `GET /_autoscaling/policy` API. As a result, the `isMlAutoscalingEnabled` flag, which we rely on in the Start Deployment modal, was always set to false. This caused a bug in scenarios with zero active ML nodes, where falling back to deriving available processors from ML limits was not possible. You can check the created deployment, it correctly identifies ML autoscaling: <img width="670" alt="image" src="https://github.com/user-attachments/assets/ff1f835e-2b90-4b73-bea8-a49da8846fbd"> Also fixes restoring vCPU levels from the API deployment params. ### Checklist Check the PR satisfies following conditions. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios (cherry picked from commit 9827a07)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
kibanamachine
added a commit
that referenced
this pull request
Nov 26, 2024
…nd 0 active nodes (#201256) (#201746) # Backport This will backport the following commits from `main` to `8.16`: - [[ML] Trained Model: Fix start deployment with ML autoscaling and 0 active nodes (#201256)](#201256) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Dima Arnautov","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-11-26T10:33:04Z","message":"[ML] Trained Model: Fix start deployment with ML autoscaling and 0 active nodes (#201256)\n\n## Summary\r\n\r\nDuring my testing, I used the current user with all required privileges\r\nbut failed to notice that, after switching to the internal`\r\nkibana_system` user, it lacked the manage_autoscaling privilege required\r\nfor the `GET /_autoscaling/policy` API.\r\n\r\nAs a result, the `isMlAutoscalingEnabled` flag, which we rely on in the\r\nStart Deployment modal, was always set to false. This caused a bug in\r\nscenarios with zero active ML nodes, where falling back to deriving\r\navailable processors from ML limits was not possible.\r\n\r\n\r\nYou can check the created deployment, it correctly identifies ML\r\nautoscaling:\r\n\r\n<img width=\"670\" alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/ff1f835e-2b90-4b73-bea8-a49da8846fbd\">\r\n\r\n\r\nAlso fixes restoring vCPU levels from the API deployment params.\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios","sha":"9827a07b5891d643a61a53e09350ff6e4ab25889","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix",":ml","v9.0.0","Feature:3rd Party Models","Team:ML","ci:cloud-deploy","ci:cloud-redeploy","backport:version","v8.17.0","v8.18.0","v8.16.2"],"title":"[ML] Trained Model: Fix start deployment with ML autoscaling and 0 active nodes ","number":201256,"url":"https://github.com/elastic/kibana/pull/201256","mergeCommit":{"message":"[ML] Trained Model: Fix start deployment with ML autoscaling and 0 active nodes (#201256)\n\n## Summary\r\n\r\nDuring my testing, I used the current user with all required privileges\r\nbut failed to notice that, after switching to the internal`\r\nkibana_system` user, it lacked the manage_autoscaling privilege required\r\nfor the `GET /_autoscaling/policy` API.\r\n\r\nAs a result, the `isMlAutoscalingEnabled` flag, which we rely on in the\r\nStart Deployment modal, was always set to false. This caused a bug in\r\nscenarios with zero active ML nodes, where falling back to deriving\r\navailable processors from ML limits was not possible.\r\n\r\n\r\nYou can check the created deployment, it correctly identifies ML\r\nautoscaling:\r\n\r\n<img width=\"670\" alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/ff1f835e-2b90-4b73-bea8-a49da8846fbd\">\r\n\r\n\r\nAlso fixes restoring vCPU levels from the API deployment params.\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios","sha":"9827a07b5891d643a61a53e09350ff6e4ab25889"}},"sourceBranch":"main","suggestedTargetBranches":["8.17","8.x","8.16"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/201256","number":201256,"mergeCommit":{"message":"[ML] Trained Model: Fix start deployment with ML autoscaling and 0 active nodes (#201256)\n\n## Summary\r\n\r\nDuring my testing, I used the current user with all required privileges\r\nbut failed to notice that, after switching to the internal`\r\nkibana_system` user, it lacked the manage_autoscaling privilege required\r\nfor the `GET /_autoscaling/policy` API.\r\n\r\nAs a result, the `isMlAutoscalingEnabled` flag, which we rely on in the\r\nStart Deployment modal, was always set to false. This caused a bug in\r\nscenarios with zero active ML nodes, where falling back to deriving\r\navailable processors from ML limits was not possible.\r\n\r\n\r\nYou can check the created deployment, it correctly identifies ML\r\nautoscaling:\r\n\r\n<img width=\"670\" alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/ff1f835e-2b90-4b73-bea8-a49da8846fbd\">\r\n\r\n\r\nAlso fixes restoring vCPU levels from the API deployment params.\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios","sha":"9827a07b5891d643a61a53e09350ff6e4ab25889"}},{"branch":"8.17","label":"v8.17.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.x","label":"v8.18.0","branchLabelMappingKey":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.16","label":"v8.16.2","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Dima Arnautov <[email protected]>
kibanamachine
added a commit
that referenced
this pull request
Nov 26, 2024
…nd 0 active nodes (#201256) (#201747) # Backport This will backport the following commits from `main` to `8.17`: - [[ML] Trained Model: Fix start deployment with ML autoscaling and 0 active nodes (#201256)](#201256) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Dima Arnautov","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-11-26T10:33:04Z","message":"[ML] Trained Model: Fix start deployment with ML autoscaling and 0 active nodes (#201256)\n\n## Summary\r\n\r\nDuring my testing, I used the current user with all required privileges\r\nbut failed to notice that, after switching to the internal`\r\nkibana_system` user, it lacked the manage_autoscaling privilege required\r\nfor the `GET /_autoscaling/policy` API.\r\n\r\nAs a result, the `isMlAutoscalingEnabled` flag, which we rely on in the\r\nStart Deployment modal, was always set to false. This caused a bug in\r\nscenarios with zero active ML nodes, where falling back to deriving\r\navailable processors from ML limits was not possible.\r\n\r\n\r\nYou can check the created deployment, it correctly identifies ML\r\nautoscaling:\r\n\r\n<img width=\"670\" alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/ff1f835e-2b90-4b73-bea8-a49da8846fbd\">\r\n\r\n\r\nAlso fixes restoring vCPU levels from the API deployment params.\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios","sha":"9827a07b5891d643a61a53e09350ff6e4ab25889","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix",":ml","v9.0.0","Feature:3rd Party Models","Team:ML","ci:cloud-deploy","ci:cloud-redeploy","backport:version","v8.17.0","v8.18.0","v8.16.2"],"title":"[ML] Trained Model: Fix start deployment with ML autoscaling and 0 active nodes ","number":201256,"url":"https://github.com/elastic/kibana/pull/201256","mergeCommit":{"message":"[ML] Trained Model: Fix start deployment with ML autoscaling and 0 active nodes (#201256)\n\n## Summary\r\n\r\nDuring my testing, I used the current user with all required privileges\r\nbut failed to notice that, after switching to the internal`\r\nkibana_system` user, it lacked the manage_autoscaling privilege required\r\nfor the `GET /_autoscaling/policy` API.\r\n\r\nAs a result, the `isMlAutoscalingEnabled` flag, which we rely on in the\r\nStart Deployment modal, was always set to false. This caused a bug in\r\nscenarios with zero active ML nodes, where falling back to deriving\r\navailable processors from ML limits was not possible.\r\n\r\n\r\nYou can check the created deployment, it correctly identifies ML\r\nautoscaling:\r\n\r\n<img width=\"670\" alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/ff1f835e-2b90-4b73-bea8-a49da8846fbd\">\r\n\r\n\r\nAlso fixes restoring vCPU levels from the API deployment params.\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios","sha":"9827a07b5891d643a61a53e09350ff6e4ab25889"}},"sourceBranch":"main","suggestedTargetBranches":["8.17","8.x","8.16"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/201256","number":201256,"mergeCommit":{"message":"[ML] Trained Model: Fix start deployment with ML autoscaling and 0 active nodes (#201256)\n\n## Summary\r\n\r\nDuring my testing, I used the current user with all required privileges\r\nbut failed to notice that, after switching to the internal`\r\nkibana_system` user, it lacked the manage_autoscaling privilege required\r\nfor the `GET /_autoscaling/policy` API.\r\n\r\nAs a result, the `isMlAutoscalingEnabled` flag, which we rely on in the\r\nStart Deployment modal, was always set to false. This caused a bug in\r\nscenarios with zero active ML nodes, where falling back to deriving\r\navailable processors from ML limits was not possible.\r\n\r\n\r\nYou can check the created deployment, it correctly identifies ML\r\nautoscaling:\r\n\r\n<img width=\"670\" alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/ff1f835e-2b90-4b73-bea8-a49da8846fbd\">\r\n\r\n\r\nAlso fixes restoring vCPU levels from the API deployment params.\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios","sha":"9827a07b5891d643a61a53e09350ff6e4ab25889"}},{"branch":"8.17","label":"v8.17.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.x","label":"v8.18.0","branchLabelMappingKey":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.16","label":"v8.16.2","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Dima Arnautov <[email protected]>
kibanamachine
added a commit
that referenced
this pull request
Nov 26, 2024
…d 0 active nodes (#201256) (#201748) # Backport This will backport the following commits from `main` to `8.x`: - [[ML] Trained Model: Fix start deployment with ML autoscaling and 0 active nodes (#201256)](#201256) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Dima Arnautov","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-11-26T10:33:04Z","message":"[ML] Trained Model: Fix start deployment with ML autoscaling and 0 active nodes (#201256)\n\n## Summary\r\n\r\nDuring my testing, I used the current user with all required privileges\r\nbut failed to notice that, after switching to the internal`\r\nkibana_system` user, it lacked the manage_autoscaling privilege required\r\nfor the `GET /_autoscaling/policy` API.\r\n\r\nAs a result, the `isMlAutoscalingEnabled` flag, which we rely on in the\r\nStart Deployment modal, was always set to false. This caused a bug in\r\nscenarios with zero active ML nodes, where falling back to deriving\r\navailable processors from ML limits was not possible.\r\n\r\n\r\nYou can check the created deployment, it correctly identifies ML\r\nautoscaling:\r\n\r\n<img width=\"670\" alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/ff1f835e-2b90-4b73-bea8-a49da8846fbd\">\r\n\r\n\r\nAlso fixes restoring vCPU levels from the API deployment params.\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios","sha":"9827a07b5891d643a61a53e09350ff6e4ab25889","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix",":ml","v9.0.0","Feature:3rd Party Models","Team:ML","ci:cloud-deploy","ci:cloud-redeploy","backport:version","v8.17.0","v8.18.0","v8.16.2"],"title":"[ML] Trained Model: Fix start deployment with ML autoscaling and 0 active nodes ","number":201256,"url":"https://github.com/elastic/kibana/pull/201256","mergeCommit":{"message":"[ML] Trained Model: Fix start deployment with ML autoscaling and 0 active nodes (#201256)\n\n## Summary\r\n\r\nDuring my testing, I used the current user with all required privileges\r\nbut failed to notice that, after switching to the internal`\r\nkibana_system` user, it lacked the manage_autoscaling privilege required\r\nfor the `GET /_autoscaling/policy` API.\r\n\r\nAs a result, the `isMlAutoscalingEnabled` flag, which we rely on in the\r\nStart Deployment modal, was always set to false. This caused a bug in\r\nscenarios with zero active ML nodes, where falling back to deriving\r\navailable processors from ML limits was not possible.\r\n\r\n\r\nYou can check the created deployment, it correctly identifies ML\r\nautoscaling:\r\n\r\n<img width=\"670\" alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/ff1f835e-2b90-4b73-bea8-a49da8846fbd\">\r\n\r\n\r\nAlso fixes restoring vCPU levels from the API deployment params.\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios","sha":"9827a07b5891d643a61a53e09350ff6e4ab25889"}},"sourceBranch":"main","suggestedTargetBranches":["8.17","8.x","8.16"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/201256","number":201256,"mergeCommit":{"message":"[ML] Trained Model: Fix start deployment with ML autoscaling and 0 active nodes (#201256)\n\n## Summary\r\n\r\nDuring my testing, I used the current user with all required privileges\r\nbut failed to notice that, after switching to the internal`\r\nkibana_system` user, it lacked the manage_autoscaling privilege required\r\nfor the `GET /_autoscaling/policy` API.\r\n\r\nAs a result, the `isMlAutoscalingEnabled` flag, which we rely on in the\r\nStart Deployment modal, was always set to false. This caused a bug in\r\nscenarios with zero active ML nodes, where falling back to deriving\r\navailable processors from ML limits was not possible.\r\n\r\n\r\nYou can check the created deployment, it correctly identifies ML\r\nautoscaling:\r\n\r\n<img width=\"670\" alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/ff1f835e-2b90-4b73-bea8-a49da8846fbd\">\r\n\r\n\r\nAlso fixes restoring vCPU levels from the API deployment params.\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios","sha":"9827a07b5891d643a61a53e09350ff6e4ab25889"}},{"branch":"8.17","label":"v8.17.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.x","label":"v8.18.0","branchLabelMappingKey":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.16","label":"v8.16.2","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Dima Arnautov <[email protected]>
paulinashakirova
pushed a commit
to paulinashakirova/kibana
that referenced
this pull request
Nov 26, 2024
…tive nodes (elastic#201256) ## Summary During my testing, I used the current user with all required privileges but failed to notice that, after switching to the internal` kibana_system` user, it lacked the manage_autoscaling privilege required for the `GET /_autoscaling/policy` API. As a result, the `isMlAutoscalingEnabled` flag, which we rely on in the Start Deployment modal, was always set to false. This caused a bug in scenarios with zero active ML nodes, where falling back to deriving available processors from ML limits was not possible. You can check the created deployment, it correctly identifies ML autoscaling: <img width="670" alt="image" src="https://github.com/user-attachments/assets/ff1f835e-2b90-4b73-bea8-a49da8846fbd"> Also fixes restoring vCPU levels from the API deployment params. ### Checklist Check the PR satisfies following conditions. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
CAWilson94
pushed a commit
to CAWilson94/kibana
that referenced
this pull request
Dec 12, 2024
…tive nodes (elastic#201256) ## Summary During my testing, I used the current user with all required privileges but failed to notice that, after switching to the internal` kibana_system` user, it lacked the manage_autoscaling privilege required for the `GET /_autoscaling/policy` API. As a result, the `isMlAutoscalingEnabled` flag, which we rely on in the Start Deployment modal, was always set to false. This caused a bug in scenarios with zero active ML nodes, where falling back to deriving available processors from ML limits was not possible. You can check the created deployment, it correctly identifies ML autoscaling: <img width="670" alt="image" src="https://github.com/user-attachments/assets/ff1f835e-2b90-4b73-bea8-a49da8846fbd"> Also fixes restoring vCPU levels from the API deployment params. ### Checklist Check the PR satisfies following conditions. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
During my testing, I used the current user with all required privileges but failed to notice that, after switching to the internal
kibana_systemuser, it lacked the manage_autoscaling privilege required for theGET /_autoscaling/policyAPI.As a result, the
isMlAutoscalingEnabledflag, which we rely on in the Start Deployment modal, was always set to false. This caused a bug in scenarios with zero active ML nodes, where falling back to deriving available processors from ML limits was not possible.You can check the created deployment, it correctly identifies ML autoscaling:
Also fixes restoring vCPU levels from the API deployment params.
Checklist
Check the PR satisfies following conditions.