Add a watch method to Workflow::Runner for event driven updates

[agrare]

Add a method for getting update driven notifications about floe events

Get all updates indefinitely:

Floe::Workflow::Runner.docker_runner.wait { |runner_context| puts runner_context }

Get only create/update events for 30 seconds then break out:

Floe::Workflow::Runner.wait(:timeout => 30, :events => %i[create update]) { |runner_context| puts runner_context }

TODO

• Kubernetes watches
• Docker events
• Podman events
• Return a compatible runner context from the wait
• Add a way to terminate the wait loop (accept a timeout option)
• Update Floe::Workflow.wait to use Floe::Workflow::Runner#wait events
• Update exe/floe to use Floe::Workflow.wait

[kbrock]

I'm getting distracted by Rename State#run_wait to just #wait
Can you pull that out to a separate PR?
It is a slam dunk.

Lol. Code climate is asking for you to add back please_hold(). I'm ok with it gone.
I had tried hard to find a way to get the complexity there down. But 4 variables that are basically the same thing just plain make it complicated for the machine (and simple for you and me)

[agrare]

Lol. Code climate is asking for you to add back please_hold(). I'm ok with it gone.

Ahh that makes so much more sense, was wondering why we pulled that out into a separate method when it was only called in one place.

[agrare]

I'm getting distracted by Rename State#run_wait to just #wait
Can you pull that out to a separate PR?

👍 yes great idea

[Fryguy]

Overall LGTM - only questions I have left are about possible JSON parsing failures as we are parsing the notices line by line.

[kbrock]

not thrilled with this.
But it is a very common pattern (i.e.: feels like go code)

[agrare]

Yeah it is my preference for any method call that could block indefinitely to take a timeout option, otherwise this is what you have to do.

kubeclient.watch_pods(:timeout => 30.seconds) would fix this :)

[miq-bot]

Checked commits agrare/floe@45c905b~...9369eef with ruby 2.7.8, rubocop 1.56.3, haml-lint 0.51.0, and yamllint
7 files checked, 0 offenses detected
Everything looks fine. 🏆

[agrare]

@kbrock @Fryguy this should be ready to go now

[Fryguy]

Is there a concurrency concern here? i.e. should we be using something from concurrent-ruby, or is Queue thread safe enough?

[agrare]

Is Queue not thread-safe? We use it in ManageIQ core across threads in a few places

[agrare]

The docs for Queue show examples using multiple threads

[Fryguy]

I can never remember hence my question - Some thing in Ruby are thread safe, others are partially and others are not. Otherwise there wouldn't be a Concurrent::Hash :(

[Fryguy]

Super-high-level I'm good with this PR (have one non-blocking question above).

In the future I wonder if it makes more sense to use something like concurrent-ruby Promises or some other abstraction. I do worry that there are hidden synchronization bugs here cause threads are hard.

[agrare]

In the future I wonder if it makes more sense to use something like concurrent-ruby Promises or some other abstraction. I do worry that there are hidden synchronization bugs here cause threads are hard.

So one of my biggest issues with Queue is there is no "timed-dequeue" so I had to add an extra thread that just did sleep+queue.put(nil). I was able to get around this by adding a Concurrent::Semaphore that has try_acquire with a timeout parameter but it started looking gross.