Revisit requeue delays, especially provisionRequeueDelay

[dtantsur]

The Ironic provisioner has a bunch of hardcoded requeue delays, all of which are at least 10 seconds. This means that even an operation like provide or abort, which normally takes a second or two, causes a 10 second delay in the provisioner.

The values have never been revisited since they were introduced up to 7 years ago.

This is a tracking bug to have a discussion and potentially reduce the delays for operations that are known to take less than 10 seconds in a normal case.

/kind bug

[dtantsur]

/cc @zaneb

Maybe you have any recollections on why the values are like this.

[Rozzii]

/triage accepted

[Rozzii]

/cc @adilGhaffarDev I think this will bring back some memories.

[dtantsur]

A potential path forward is to merge-then-split all these values into actually two: for short actions (~ 2s) and long actions (keep 10s). Actions such as manage, provide with disabled cleaning, abort, as well as retries for locked nodes tend to be rather short in most cases. The only long actions are the ones that involve booting a ramdisk or reboots: inspecting, cleaning, servicing, deploying.

[zaneb]

I think when these were created we were largely only doing slow stuff, and people just reused the existing constants.

[dtantsur]

/help

I can do the change myself, but I'd be happy if someone took it over - it's not very hard.

[metal3-io-bot]

@dtantsur:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

Details

In response to this:

/help

I can do the change myself, but I'd be happy if someone took it over - it's not very hard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[Sunnatillo]

/assign