Memory Limit absent

[Nihar Ranjan Mishra]

Hello, Why NHC, SNR and FAR controller manager do not have limit defined in case of memory ? Thanks

[Carlo Lobrano]

Hello,

Thank you for pointing that out. NHC and SNR are actually missing the limits.
FAR controller has them correctly set https://github.com/medik8s/fence-agents-remediation/blob/78139f2f3c2e2611863ae3bce25ac5b375d78d97/bundle/manifests/fence-agents-remediation.clusterserviceversion.yaml#L411-L414

[Nihar Ranjan Mishra]

Thanks Carlos! Is there any chance of integrating the limits with SNR and NHC manifests in future ? 

Nihar

--
You received this message because you are subscribed to the Google Groups "medik8s" group.
To unsubscribe from this group and stop receiving emails from it, send an email to medik8s+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/medik8s/2e0fd0e9-7942-4a42-a6d7-4150bba6114bn%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Nihar

[Carlo Lobrano]

Hi already opened the tickets to track the work. Just at the moment I can't plan when the change will be integrated

[Michael Shitrit]

Hi Nihar, 

Thanks for pointing out this issue.
We always welcome contributions, so if you'd like to give it a try it'll be much appreciated!

To view this discussion visit https://groups.google.com/d/msgid/medik8s/5ba79dee-7208-4d79-8011-cd4f7707fa11n%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Michael Shitrit

Principal Software Engineer

Red Hat

[Nihar R Mishra]

Thanks micheal . Sure I can give it a try once I have some bandwidth .

 One thing regarding the limit I assumed that the reason the memory and cpu is not specified due to the fact that the snr far and nhc pod must not go oom or shall not be interrupted irrespective of cluster state because when there is a remediation is in progress it might not be completed with a clear and acceptable status also that may lead to data corruption for the state fulstates workloads due to their RWO nature . This is one of the scenarios which would require the workload availability workloads to be up and running all the time.

Let me know thanks 

Nihaar 

To view this discussion visit https://groups.google.com/d/msgid/medik8s/CALOzty%3DX3ZTHS94tgZvXiYj8ey07s6zda3N5btepzheCvB%2BokQ%40mail.gmail.com.

[Michael Shitrit]

That's correct.
In a nutshell they perform a critical operation that is likely to happen on an already stressed cluster, and we want to ensure it follows through.

It makes sense to discuss the ticket regarding any limitations we want to apply before starting a PR.

[Michael Shitrit]

Adding links to the tickets:
https://redhat.atlassian.net/browse/RHWA-1189

https://redhat.atlassian.net/browse/RHWA-1188

[Carlo Lobrano]

I was informed that resource limits in controllers are discouraged, and I'll update the tickets accordingly.
See: https://redhat-best-practices-for-k8s.github.io/guide/#_requests_and_limits_in_kubernetes

Nihar, could you clarify why you're requesting resource limits?

[Nihar Ranjan Mishra]

Thanks for the link! It makes total sense why the documentation advises against setting resource limits.

However, we noticed a bit of a contradiction: FAR still has limits defined based on the earlier documentation shared with us. Could you clarify why there’s a discrepancy between the two guidelines, and if there are any plans to roll back those limits (FAR) to align with this new document?

We are currently deploying our applications into a cluster alongside Workload Availability and other operators. We want to ensure cluster stability and are trying to determine the best path forward. -  Should we follow the new guide strictly, or should we actively restrict the Workload Availability pods to prevent them from consuming unbounded memory?

 Let me know.

Nihaar.