GutoVeronezi commented on PR #8605: URL: https://github.com/apache/cloudstack/pull/8605#issuecomment-2023718630
@andrijapanicsb, I made some changes in the PR's title and description to make the proposal clearer. To put us on the same page, the proposal with this PR is to flexibilize the timeout of the commands MS sends to the agents. It was never aimed to provide API calls for operators/users. 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, there are specific global settings, like `kvm.storage.online.migration.wait` and `kvm.storage.offline.migration.wait`. Externalizing global settings for each command to provide flexibility is not interesting, as we would increase the number of global settings by almost 50%(we would also have the work to create and describe every setting, which you mentioned "doesn't sound feasible"). Furthermore, if we continue working with global settings, each command timeout externalization would require the process of (i) providing the use case; (ii) extending the platform; and (iii) waiting for a release. We know that process can take several months and, if you are an operator, you know that waiting months for a simple timeout configuration is not feasible. The proposal is to create a mechanism to allow operators to define the timeout of the commands MS sends to the agents dynamically and in a flexible fashion. The first phase is focused on the definition of the concept; thus, it is expected to be more developer-friendly at first. However, we already have the next steps planned, as you can see in https://github.com/apache/cloudstack/issues/8506#issuecomment-1924648687, and those will make the feature user/operator-friendly (via API and GUI). Indeed, the process of documenting all the commands will require some work, but we have contributors who are willing to do that (me and some others); thus, as it will not require efforts from the operators to document them, I do not see the problem. It is also important to mention that it is a new feature and the current behavior is kept; thus, you do not need to use the feature if you do not want. If you have another effortless and more straightforward proposal that addresses all of the use cases we are talking about, I would be glad to discuss it with you. Regarding the timeout of the API calls the users do the MS, as they are a different context, we can create another issue to discuss it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
