| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Codecov ReportAttention: Patch coverage is 37.50000% with 25 lines in your changes missing coverage. Please review.
@@ Coverage Diff @@
## main #8605 +/- ##
===========================================
Coverage 15.28% 15.28%
- Complexity 11535 11538 +3
===========================================
Files 5424 5426 +2
Lines 474334 474361 +27
Branches 60970 58437 -2533
===========================================
+ Hits 72498 72503 +5
- Misses 393778 393804 +26
+ Partials 8058 8054 -4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Sorry, something went wrong.
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
Sorry, something went wrong.
There was a problem hiding this comment.
i think this does what you proposed (clgtm) but we have to think about versions and upgrade paths
Sorry, something went wrong.
|
@GutoVeronezi thx for the detailed explanation on this one, I guess we'll have to go with that - I'm now more clear on the idea, and, indeed, it doesn't align with what I was "expecting" to be able to do as on operator, that would have to be a separate effort/PR |
Sorry, something went wrong.
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
Sorry, something went wrong.
|
@GutoVeronezi do we need more work on this? (except for conflict resolution) |
Sorry, something went wrong.
I think we are good with the code; however, I want to try it a bit more and post the tests. |
Sorry, something went wrong.
|
@DaanHoogland a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
Sorry, something went wrong.
|
Packaging result [SF]: ✔️ el7 ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 9787 |
Sorry, something went wrong.
|
@DaanHoogland a [SL] Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
Sorry, something went wrong.
|
[SF] Trillian test result (tid-10370)
|
Sorry, something went wrong.
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Description
Currently, almost every command MS sends to the agents uses the global setting wait as the timeout's value. That means, if you want to extend or shorten the execution of a command, you will affect every other command. Therefore, currently we do not have a way to customize the timeout for specific commands.
For some edge cases, we have "wait"/"timeout" hardcoded values or values that come from global settings to set the commands timeout, like for GetAutoScaleMetricsCommand and for MigrateCommand. Currently, we have 385 classes that extend com.cloud.agent.api.Command (I skipped classes that extend com.cloud.agent.api.Answer); therefore, externalizing global settings for each command to provide flexibility is not feasible; however, we can reach flexibility by other means.
Currently, if we do not set a wait to the command, AgentManagerImpl will fallback to the wait global setting:
cloudstack/engine/orchestration/src/main/java/com/cloud/agent/manager/AgentManagerImpl.java
Lines 441 to 443 in af8a582
I propose to create a table of command_timeout to store the classpath of the command and its wait/timeout. Then, instead of fall backing directly to the wait global setting, we check if there is an entry of the command in this table. If it exists, then we use the entry's value; otherwise, we fall back to the wait global setting (the current behavior). Thus, we can change the commands wait/timeout on demand and in a flexible way.
The first step of the proposal is to create the table and changing AgentManagerImpl to check the table. Some entries will already be created for hardcoded values. Further steps can be found in #8506.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
How Has This Been Tested?
TBD