[FIO] Add CLI args for affinities and tolerations

[smasset-orange]

Inspired from #105 but using node affinities (instead of setting Node attribute) and also handling different operators.

[smasset-orange]

This is my very first attempt at writting Go code so please feel free to suggest improvements.

I'm off on vacation so also don't hesitate to update the code as you feel if you don't get any update from me.

[smasset-orange]

/cc @ihcsim @mmotejlek, here's another take at #105, please have a look

[mmotejlek]

The idea of using affinities + tolerations looks good to me. I had realized that if nodeSelector or nodeAffinity was used, it'd be necessary to implement tolerations too. EDIT: See below

Unless there's a standard way that I'm unaware of, I'd extend syntax for tolerations by:

• Universal toleration: :
• Universal effect specifier: :NoSchedule (for example)

And for easier parsing it wouldn't be bad to allow colon at the end like this: key=value:

EDIT: See comment below

Personally I'd move the user input parsing and validation logic to the cmd package together with related tests, the RunFIOArgs struct would take Kubernetes library objects. Or at the very least I'd move the parsing+validation out of fioStepper implementations, but since RunFioHelper takes RunFIOArgs as an input, fewer changes would be required if parsing was in the cmd package and RunFIOArgs contained Kubernetes library objects.

I can continue on the work.

[mmotejlek]

Update upon the syntax for tolerations suggested above:

key[=value][:effect]|:effect, where effect can be Any

This removes the standalone and trailing colon from the previous idea.

[ihcsim]

From a UX perspective, I think like it's easier to work with node selector, than affinity and toleration (i.e. label k/v pairs vs. expresssion). It also allows us to achieve the original goal of scheduling the FIO pod on specific nodes with less code.

[mmotejlek]

(I deleted my previous comment because it turned out some things weren't the way I had thought)

Regarding:

I had realized that if nodeSelector or nodeAffinity was used, it'd be necessary to implement tolerations too.

I was wrong about this, I didn't realize that it's possible to just hardcode a universal toleration for the pod (or maybe make it a switch).

I think it'll be the best to implement nodeSelector as that's what was needed in the first place and leave room for a possible extension towards Kubectl's --selector syntax, which is a superset of a StringToString flag, unlike the syntax used in this PR (because of the way commas are treated).

Sidenote: The --selector flag is parsed by this function: https://pkg.go.dev/k8s.io/apimachinery/pkg/labels#Parse. It should be possible to use it for an extension of the node selection feature by converting Parse's output into a corresponding NodeAffinity (note that --selector does not have all the capabilities of NodeAffinity).

I'll go back to #105 and implement node selector as originally planned.

[ihcsim]

@smasset-orange thanks again for this PR. For now, we will limit the scope to #105. If you are interested in working on more Go issues, feel free to check out the issues list. Also, we have another open source project named Kanister, which is a data protection workflow engine, with even more interesting issues. Cheers!