Set CPU and Memory resources for the metrics exporter container

[apeduru-patreon]

Is your feature request related to a problem? Please describe.
We have a custom OPA admission controller policy that watches for and rejects containers that do not have CPU and Memory resources defined. The locust-metrics-exporter in fact does not have these resources set so when spinning up the locust master worker it errors out as seen in this error message below.

�[32m2023-08-16 19:34:49,414�[0;39m �[34mINFO �[0;39m [�[34mReconcilerExecutor-locusttestreconciler-26�[0;39m] �[33mcom.locust.operator.controller.utils.resource.manage.ResourceCreationManager�[0;39m: Creating Job for:loadtest-master in namespace: locust
�[32m2023-08-16 19:34:57,014�[0;39m �[1;31mERROR�[0;39m [�[34mReconcilerExecutor-locusttestreconciler-26�[0;39m] �[33mcom.locust.operator.controller.utils.resource.manage.ResourceCreationManager�[0;39m: Exception occurred during Job creation: Failure executing: POST at: https://172.20.0.1/apis/batch/v1/namespaces/locust/jobs. Message: Forbidden!Configured service account doesn't have access. Service account may have been revoked. admission webhook "validation.gatekeeper.sh" denied the request: [container-must-have-resources] container <locust-metrics-exporter> has no resource limits.
io.fabric8.kubernetes.client.KubernetesClientException: Failure executing: POST at: https://172.20.0.1/apis/batch/v1/namespaces/locust/jobs. Message: Forbidden!Configured service account doesn't have access. Service account may have been revoked. admission webhook "validation.gatekeeper.sh" denied the request: [container-must-have-resources] container <locust-metrics-exporter> has no resource limits.
	at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.requestFailure(OperationSupport.java:713)
	at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.requestFailure(OperationSupport.java:693)
	at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.assertResponseCode(OperationSupport.java:642)
	at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.lambda$handleResponse$0(OperationSupport.java:581)
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture.postComplete(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture.complete(Unknown Source)
	at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.lambda$retryWithExponentialBackoff$2(OperationSupport.java:622)
	at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture.postComplete(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture.complete(Unknown Source)
	at io.fabric8.kubernetes.client.okhttp.OkHttpClientImpl$4.onResponse(OkHttpClientImpl.java:268)
	at okhttp3.RealCall$AsyncCall.execute(RealCall.java:203)
	at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

Describe the solution you'd like
I've implemented a solution in this PR: #131
which reuses the same resources defined for the load gen container.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[apeduru-patreon]

Hi @AbdelrhmanHamouda, for your consideration

[AbdelrhmanHamouda]

Hello @apeduru-patreon,
Thank you for taking the time to both, open the issue and contribute a solution for it. I checked the fix and I believe it will work. That being said, I have an observation that makes me want to investigate an alternative solution.

Basically, with the currently proposed solution, the "master" pod will have 2X the resources and possibly under-utilising the "metrics exporter" ones.
I'm thinking of introducing new configuration values just for the metrics exporter so you would be able to configure it like you do the other pods.

[AbdelrhmanHamouda]

Update: I am working on the proposal mentioned in the previous message and will be pushing it soon.

This change will default to the current exporter but will allow the metrics exporter to be fully configurable through helm overrides:

• Image
• Image pullPolicy
• Port
• Resources Request
• Resources Limits

[naga-awone]

ability to set custom image for metrics will be cool

[AbdelrhmanHamouda]

This is indeed included in the new version to be pushed. However, it is important to stress that the operator will guarantee an "out of the box" integration with default exporter, if a user chose to opt for another exporter, they must make sure that it is compatible with the operator.

[AbdelrhmanHamouda]

@apeduru-patreon Thank you so much for the contribution and for taking the time to go through the project and find where to do the change.

As discussed in the issue, I had some concerns about the actual resource utilisation of the proposed solution. However, I understand that this is a blocking issue for you in the organisation and thus, the latest version of the operator V0.8.0, fully support the mentioned use case.

The Metrics exporter will now request resources by default and it is possible to control exactly the amounts requested (HELM VALUES).

Please feel encouraged to try out the new version and let me know if it is matching your expectations