Add option for operator to set resource claims on daemonset containers

Change description

Add option for operator to set resource claims on daemonset containers

The operator installation of trident currently does not allow setting resource requests and limits for the daemonset containers. With this change the option is added through the TridentOrchestrator crd to set specific resource requests and limits. If no resource requests or limits are set, the current default values are respected.

Project tracking

N/A

Do any added TODOs have an issue in the backlog?

Did you add unit tests? Why not?

Added unit tests for the construction of the resource yaml fields.

Does this code need functional testing?

Is a code review walkthrough needed? why or why not?

I hope the MR is quite straight forward but I'm open for a walkthrough if it helps to get this MR through.

Should additional test coverage be executed in addition to pre-merge?

Does this code need a note in the changelog?

Yes, two extra fields have been added to the tridentorchestrator crd:

apiVersion: trident.netapp.io/v1
kind: TridentOrchestrator
spec:
  dsRegistrarResources: {}
  dsTridentResources: {}

The old default values are being respected when these fields are not set. In case they are set, they will configure the trident daemonset according to the corev1 resourceRequirements field.

Does this code require documentation changes?

Additional Information

Currently we're using the trident operator install on a cluster with about ~90 nodes. The trident-node-linux daemonset that the operator generates does not have any resources requests / limits specified. Because of this the pods inherit the resources requests / limits that the are being set by the limitrange object from our rancher setup. This results both in way too many resources being claimed. With this MR we hope to get some more control over the daemonset this is being generated by the operator.

NetApp / trident