-
Notifications
You must be signed in to change notification settings - Fork 8
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
Run workflows asyncrhonously on MiqAutomationWorker #50
Run workflows asyncrhonously on MiqAutomationWorker #50
Conversation
app/models/manageiq/providers/workflows/automation_manager/workflow_instance.rb
Outdated
Show resolved
Hide resolved
wf.step | ||
wf.run_nonblock |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
@@ -87,6 +89,6 @@ def run(args = {}) | |||
object.after_ae_delivery(ae_result) | |||
end | |||
|
|||
run_queue(:zone => zone, :role => role, :object => object) unless wf.end? | |||
run_queue(:zone => zone, :role => role, :object => object, :deliver_on => 1.minute.from_now.utc) unless wf.end? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
think I want to expose wf.waiting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I was hoping to contain that knowledge inside the .wait
method
spec/models/manageiq/providers/workflows/automation_manager/workflow_instance_spec.rb
Outdated
Show resolved
Hide resolved
8c502d1
to
0589b64
Compare
Rather than running each step in a single queue message synchronously, execute WorkflowInstances asynchronously and requeue once the workflow would block.
0589b64
to
98832ba
Compare
Checked commits agrare/manageiq-providers-workflows@98832ba~...2d1adb9 with ruby 2.6.10, rubocop 1.28.2, haml-lint 0.35.0, and yamllint |
@@ -87,6 +90,6 @@ def run(args = {}) | |||
object.after_ae_delivery(ae_result) | |||
end | |||
|
|||
run_queue(:zone => zone, :role => role, :object => object) unless wf.end? | |||
run_queue(:zone => zone, :role => role, :object => object, :deliver_on => 10.seconds.from_now.utc, :server_guid => MiqServer.my_server.guid) unless wf.end? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@agrare Is this what you mentioned to me?
So my question here is why we need the pinning and deliver time at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because this re-queue while the docker/podman/k8s task is still running so we don't want it to spin (hence deliver on) and we need to run it on the same server so podman inspect
will be able to see the running container.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ohhh I see - ok, this is what I wasn't understanding in our discussion yesterday because I thought it worked differently.
Backported to
|
…rker Run workflows asyncrhonously on MiqAutomationWorker (cherry picked from commit be6f4d1)
Depends on: