[WIP] Remove wait_for_worker_monitor functionality #14257
Closed
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
|
This pull request is not mergeable. Please rebase and repush. |
|
Talked to @carbonin on this one, and we've come to realize that the wait_for_worker_monitor functionality has become essentially a wait barrier for dependent workers that is implemented via waiting for MiqServer to transition to Here is a chart depicting how it all works |
Fryguy
force-pushed
the
remove_wait_for_worker_monitor
branch
from
befcfde to
e2cdcab
Compare
|
Checked commit Fryguy@e2cdcab with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
Fryguy
added a commit
to Fryguy/manageiq
that referenced
this pull request
Jul 25, 2017
A majority of workers do not need to wait for the server to start, so changing the default simplifies the code and also identifies which workers actually need to wait. In researching this, we found that the only reason that workers are waiting is to actually wait for the vmware broker to start and provide its connection pool. Follow up PRs will change this from wait_for_worker_monitor to "wait for broker", and we can further make this more specific to vmware only classes. See also ManageIQ#14257 (comment) for a description of how the wait_for_worker_monitor manifests as a "wait for broker" scenario.
|
This pull request is not mergeable. Please rebase and repush. |
agrare
pushed a commit
to agrare/manageiq-providers-vmware
that referenced
this pull request
Aug 21, 2017
A majority of workers do not need to wait for the server to start, so changing the default simplifies the code and also identifies which workers actually need to wait. In researching this, we found that the only reason that workers are waiting is to actually wait for the vmware broker to start and provide its connection pool. Follow up PRs will change this from wait_for_worker_monitor to "wait for broker", and we can further make this more specific to vmware only classes. See also ManageIQ/manageiq#14257 (comment) for a description of how the wait_for_worker_monitor manifests as a "wait for broker" scenario. (transferred from ManageIQ/manageiq@9e99ba0)
agrare
pushed a commit
to agrare/manageiq-providers-vmware
that referenced
this pull request
Aug 23, 2017
A majority of workers do not need to wait for the server to start, so changing the default simplifies the code and also identifies which workers actually need to wait. In researching this, we found that the only reason that workers are waiting is to actually wait for the vmware broker to start and provide its connection pool. Follow up PRs will change this from wait_for_worker_monitor to "wait for broker", and we can further make this more specific to vmware only classes. See also ManageIQ/manageiq#14257 (comment) for a description of how the wait_for_worker_monitor manifests as a "wait for broker" scenario. (transferred from ManageIQ/manageiq@9e99ba0)
|
Fairly sure we can close this in favor of #15654 |
agrare
pushed a commit
to agrare/manageiq-providers-vmware
that referenced
this pull request
Dec 19, 2017
A majority of workers do not need to wait for the server to start, so changing the default simplifies the code and also identifies which workers actually need to wait. In researching this, we found that the only reason that workers are waiting is to actually wait for the vmware broker to start and provide its connection pool. Follow up PRs will change this from wait_for_worker_monitor to "wait for broker", and we can further make this more specific to vmware only classes. See also ManageIQ/manageiq#14257 (comment) for a description of how the wait_for_worker_monitor manifests as a "wait for broker" scenario. (transferred from ManageIQ/manageiq@9e99ba0)
agrare
pushed a commit
to agrare/manageiq-providers-vmware
that referenced
this pull request
Mar 23, 2018
A majority of workers do not need to wait for the server to start, so changing the default simplifies the code and also identifies which workers actually need to wait. In researching this, we found that the only reason that workers are waiting is to actually wait for the vmware broker to start and provide its connection pool. Follow up PRs will change this from wait_for_worker_monitor to "wait for broker", and we can further make this more specific to vmware only classes. See also ManageIQ/manageiq#14257 (comment) for a description of how the wait_for_worker_monitor manifests as a "wait for broker" scenario. (transferred from ManageIQ/manageiq@9e99ba0)
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.
@carbonin @jrafanie Here is a WIP of killing wait_for_worker_monitor. I'd like to try this out on an appliance with you both.