-
Notifications
You must be signed in to change notification settings - Fork 9.6k
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
Feature: Print actions in progress during apply #5932
Comments
I remember @mitchellh was mentioning at the last London HUG meetup that he plans to work on this. I suggested it should not be as simple as I assume this would require more changes in the core though, it would be hard to introduce without breaking provider plugin interface and I'm not sure if the value is worth it. |
@radeksimko I think we start with the simple approach, since we can do that for free without any core changes right now. Otherwise its probably a pretty deep core change. |
During `apply` and `destroy` commands, prints the current set of resources if no apply step has started or stopped within ten seconds. Fixes hashicorp#5932.
See #6032 |
During `apply` and `destroy` commands, prints the current set of resources if no apply step has started or stopped within ten seconds. Fixes hashicorp#5932. Note: this removes the wrapping of UiHook.Ui in a ConcurrentUi, because it appears that it is already a ConcurrentUi when constructed in Meta anyway. Since there are now two hooks that share the Ui, what's important is that the underlying Ui passed to both hooks is concurrent; the fact that UiHook's is itself concurrent is distracting.
During `apply` and `destroy` commands, prints the current set of resources if no apply step has started or stopped within ten seconds. Fixes hashicorp#5932. Note: this removes the wrapping of UiHook.Ui in a ConcurrentUi, because it appears that it is already a ConcurrentUi when constructed in Meta anyway. Since there are now two hooks that share the Ui, what's important is that the underlying Ui passed to both hooks is concurrent; the fact that UiHook's is itself concurrent is distracting.
During `apply` and `destroy` commands, prints the current set of resources if no apply step has started or stopped within ten seconds. Fixes hashicorp#5932. Note: this removes the wrapping of UiHook.Ui in a ConcurrentUi, because it appears that it is already a ConcurrentUi when constructed in Meta anyway. Since there are now two hooks that share the Ui, what's important is that the underlying Ui passed to both hooks is concurrent; the fact that UiHook's is itself concurrent is distracting.
During `apply` and `destroy` commands, prints the current set of resources if no apply step has started or stopped within ten seconds. Fixes hashicorp#5932. Note: this removes the wrapping of UiHook.Ui in a ConcurrentUi, because it appears that it is already a ConcurrentUi when constructed in Meta anyway. Since there are now two hooks that share the Ui, what's important is that the underlying Ui passed to both hooks is concurrent; the fact that UiHook's is itself concurrent is distracting.
During `apply` and `destroy` commands, prints the current set of resources if no apply step has started or stopped within ten seconds. Fixes hashicorp#5932. Note: this removes the wrapping of UiHook.Ui in a ConcurrentUi, because it appears that it is already a ConcurrentUi when constructed in Meta anyway. Since there are now two hooks that share the Ui, what's important is that the underlying Ui passed to both hooks is concurrent; the fact that UiHook's is itself concurrent is distracting.
During `apply` and `destroy` commands, prints the current set of resources if no apply step has started or stopped within ten seconds. Fixes hashicorp#5932. Note: this removes the wrapping of UiHook.Ui in a ConcurrentUi, because it appears that it is already a ConcurrentUi when constructed in Meta anyway. Since there are now two hooks that share the Ui, what's important is that the underlying Ui passed to both hooks is concurrent; the fact that UiHook's is itself concurrent is distracting.
During `apply` and `destroy` commands, prints the current set of resources if no apply step has started or stopped within ten seconds. Fixes hashicorp#5932. Note: this removes the wrapping of UiHook.Ui in a ConcurrentUi, because it appears that it is already a ConcurrentUi when constructed in Meta anyway. Since there are now two hooks that share the Ui, what's important is that the underlying Ui passed to both hooks is concurrent; the fact that UiHook's is itself concurrent is distracting.
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
During a long apply with many resources being affected, it can be hard to tell what's actually going on. To figure out what resources are currently being created, modified, or destroyed you have to scan the entire output and ignore whatever has had its "complete" message already.
I think UiHook should (optionally? by default? with configurable timeout?) print messages reminding you what's in progress every so often. eg, if it's been 10 seconds since the last message of any sort printed, it should print a reminder of what resources are currently in progress. (A simpler version would be to just print the message every 10 seconds no matter what, but I think it's a little nicer if it only shows up when terraform is otherwise idle.)
UiHook already tracks these resources in its
resources
map. All that's required is to create a goroutine that prints in the background from... somewhere, I'm not sure where. (I'm not even quite sure where the UiHook comes from: there's one constructed incommand.Meta.contextOpts
and one incommand.Config.ContextOpts
... but maybe the latter is dead code?)The text was updated successfully, but these errors were encountered: