Implement runner#wait in a generic way

[kbrock]

pulled out of #178

Depend upon:

• Make Runner#wait optional #190

Overview

The builtin runner does not need a wait method since it does not listen to completed tasks. But other runners may need a a wait.

So the solution is to make wait optional, and setup a thread for all the runners that implement that interface.

Before

Run a thread to support wait from "docker" runner, but no others.

After

Run a thread for every runner that requires wait.

Developer speak

# handle docker scheme
Thread.new do
  loop do
    Runner.for_resource("docker").wait do |event, runner_context|
      queue.push([event, runner_context])
    end
  end
end

aka:

# handle docker scheme
runner = Runner.for_resource("docker")
Thread.new do
  loop do
    runner.wait do |event, runner_context|
      queue.push([event, runner_context])
    end
  end
end

handling multiple runners:

# handle all schemes
Runner.runners.each do |runner|
  Thread.new do
    loop do
      runner.wait do |event, runner_context|
        queue.push([event, runner_context])
      end
    end
  end
end

Aside

I had wanted to add something with exe/floe's interface, since that is also hard coded, but this addresses my primary concerns.

[agrare]

@kbrock if we don't have a wait thread what is going to unblock the queue.pop

            # Block until an event is raised
            event, runner_context = queue.pop

[kbrock]

@agrare That thread is only needed to handle the async nature of the "docker" runner. I commented out the "docker" thread and was able to run a workflow just fine:

{
  "StartAt": "a",
  "States": {
    "a":{
      "Type": "Pass",
      "Next": "b"
    },
    "b": {
      "Type": "Wait",
      "Seconds": 1,
      "Next": "c"
    },
      "c": {
        "Type": "Succeed"
    }
  }
}

ASIDE: was also able to call with an awesome:// Task without this thread

[kbrock]

this is a lazy eval, but it caches the result on the first call.
I do wonder if this is not thread safe. Ruby's GPL probably takes care of it.

[kbrock]

This is essentially @runners.values resolving the procs.

I'm realizing that on startup 100% of runners are procs.
But after 1 task is run, 0% of runners are procs.
Wonder if we can do a resolve up front so we don't have to handle this case during regular runtime activity.

---

I feel supporting multiple schemes by a single runner is currently far fetched.
Ignoring that use case allows us to keep to our current simple runner registration process: Floe::Runner.register_scheme.

In the future, if we come up with a case where there are multiple schemes, we can make our registration process more complicated.

[kbrock]

@Fryguy re: use case

I had implemented #178 using a synchronous/blocking implementation (first commit) and an async/event implementation (second commit)

The sync/blocking implementation works fine without this PR.
But if we have events triggered once the process is complete, then we need the wait thread to process these events.

This PR provides the thread for any runner that needs one.

[kbrock]

some runners do not have async events.
Putting an empty method into wait calls an empty method in a tight loop.
So having a switch that says a thread is not needed seems the best route (i.e.: not defining wait.

[miq-bot]

Checked commit kbrock@7e419b0 with ruby 2.7.8, rubocop 1.56.3, haml-lint 0.51.0, and yamllint
2 files checked, 0 offenses detected
Everything looks fine. 🏆

[kbrock]

reducing branches: handle this with awesome_spawn