Add --timeout flag to fluxctl

[suvl]

In our cluster, there's a few operations that almost always take more than 60 seconds. sync is the most sensitive for us, as we use it from tools like Jenkins and Azure DevOps to assert that our changes were applied to the cluster.

The hard-coded timeout prevented us from having a nice deterministic pipeline, so we need to change it: we added the --timeout <int> argument and it'll also be looking to the FLUX_TIMEOUT env variable.

[squaremo]

This is a nice idea 👍

Is there an advantage to having the timeout in fluxctl, rather than using e.g., timeout 2m fluxctl sync?

I can think of one: it'll be available in environments which don't have GNU coreutils, e.g., Windows -- and since you mentioned Azure, perhaps that's an important advantage for you :-)

[suvl]

@squaremo well, doin' it with timeout is a quite nice idea, but since the timeout is currently hard-coded, and as you said it can be advantageous in some cases, I still would like to see a setting/env var on this.

[hiddeco]

This PR will probably solve #1857.

[hiddeco]

Given the issue I mentioned I think this is a good change and will even solve some edge case scenarios people are having issues with at the moment.

Please take a look at my comments (all about code style and not so much about the contents of the PR itself).

[suvl]

@hiddeco I've accepted all proposed changes.

[squaremo]

This PR will probably solve #1857.

That would be nice, but I don't think it will happen this time -- this PR changes how long fluxctl will keep polling for a job to complete, but the job timeout internal to fluxd remains the same.

[squaremo]

I still would like to see a setting/env var on this.

Fair enough -- no objection here.

[hiddeco]

That would be nice, but I don't think it will happen this time -- this PR changes how long fluxctl will keep polling for a job to complete, but the job timeout internal to fluxd remains the same.

Ah, you are right 😞

---

@suvl looking good, tests are failing due to the introduced timeout var not being set in TestReleaseCommand_CLIConversion. You can run the tests on your own machine by running make test (to confirm you fixed the issue), in addition, can you smash your commits together once this has been fixed?

[2opremio]

@suvl are you planning to continue working on this? If that's the case, please revise on master since we have recently moved to go modules, which is causing a conflict

[suvl]

@2opremio yeah sorry I was away for a time, but yeah planning on fixing the tests and now on fixing the merge from master.

[squaremo]

fixing the merge from master.

Please rebase on master rather than merging. Usually there will be no conflicts. If you need a hand though, let us know.

EDIT: After re-reading the thread, I think that's what you meant. As you were :-)

[hiddeco]

Can't review this myself again as I have touched the code, @stefanprodan / @squaremo PTAL.

[stefanprodan]

LGTM