Add Task#Retrier incremental backoff and Wait#Timestamp

[kbrock]

Change Wait#running?

I feel running? should read the state to see if the task is complete but should not change the state.

This change was also introduced to be reusable by Task#wait.

Before

running? checks if we have passed the amount of time necessary. Once it is no longer running, this method sets the state["EndTime"].

After

start sets the target time when this will end. running? just checks Time.now agains the predefined value.

• This allows all 4 of the time options to be used without evaluating them over each tick.
• running? no longer modifies state
• This allows us to expose the expectation for when this will finish to the workflow engine. So it can use sleep or MiqQueue#deliver_on.

Wait#SecondsPath wait ref

The existing Seconds parameter reads the wait time out of the payload. The new SecondsPath reads the wait time out of the input.

Wait#Timestamp, Wait#TimestampPath

While the existing Seconds parameter is a delta, and the new Timestamp parameter is an absolute time. The TimestampPath parameter is the equivalent, but the value comes from the input.

The implementation for Timestamp and TimestampPayload are not very different from Seconds. wait ref

Task#retry

A retrier specifies how many times to re-run a Task after it fails. But the current code does not delay the retry. More information on the retry delay logic can be found in the ref

Before

A task retry does not introduce a delay so there is no incremental backoff. The retrier does allow you to define it, but it is not used. You will notice the TODO removed from this PR.

After

We do a non-blocking sleep similar to Wait when a task has a failure. Since the Task#wait implementation is based upon Sleep#wait, I bundled them together.

Removed

Extracted workflow#wait_until to another PR.

[kbrock]

update:

• rebased to include string dates
• storing wait as a string

update:

• Workflow#wait_until

[kbrock]

update:

• rebased
• changed comment around adding success states to make it obvious that it is a development feature

[kbrock]

update:

• helper method value_or_path to simplify implementation of using a path or value
• was able to put the wait() call back into Wait#start (vs rubocop encouraged separate method)
• test for wait_until

[kbrock]

Updates:

• rebased onto cops (had a conflict when adding timecop gem)
• fixed cops related to hashrocket and extra newline

[Fryguy]

Can you describe the problem you are trying to solve in the OP? It;'s hard to understand what problem/feature this is trying to solve.

Saw the little refs in the OP - are those new features being added here?

[kbrock]

update:

• split timecop/spec changes addition to own commit (to show it is green before/after)
• rebased
• removed wait_until

[miq-bot]

Checked commits https://github.com/kbrock/floe/compare/7d3af1713c50d4c8099043fa4a3340e67b193081~...5eff318d4ce3ebc746860713ac667d4c28768ba0 with ruby 2.6.10, rubocop 1.28.2, haml-lint 0.35.0, and yamllint 8 files checked, 0 offenses detected Everything looks fine. :+1: