Add common linter check to ensure that all operator/managers defined the resource request

[operator-framework]

Add common linter check to ensure that all operator/managers defined the resource request

[fgiloux]

I would vote for starting with warning on missing resource requests. Independent on all the good points made for the need to have request resources set it is not a good user experience when you have something that used to work and suddenly the validation starts to fail when actually you have not changed anything that justifies it. At least if we decide to fail the test later on they will have been warned beforehand and it would not come as a surprise.

[camilamacedo86]

Hi, @tlwu2013 and @dmesser,

So, concerns were raised against adding the validator to enforce/fail when the requested resource is not set. In this way, I'd like to add here and share the mainly strongest argumentations for both cases:

The motivation to mandatory ask for authors to set at least the resource request is:

• If a LimitRange is activated in a namespace for computing resources like CPU and memory, users must specify requests or limits for those values. Otherwise, the system may reject Pod creation.
• If a resourQuota be configured and the pods do not have at least requests or limits for those values the system may reject Pod creation.

And then, the above configuration is commonly adopted and recommended in multi-tenancy and or production clusters where OLM is used usually. More info: https://github.com/operator-framework/operator-sdk/pull/5353/files

The argumentation against making the request resource mandatory is:

• We want these operator authors to set GOOD resource requests. To create good resource requests, operator authors will need time and customer usage data.

NOTE: An against argumentation here is that: the Operator Authors can do tests and benchmarks before publishing their first solution or indeed adopting reasonable init values for the requests such as:

  resources:
    requests:
      cpu: 10m
      memory: 64Mi

• Usually, we only make mandatory what will explicitly not work well with OLM and that shows to be more an indirectly need/requirement.

Additionally, another idea was raised as well: giving operators a "badge" in the UI when the operator meets these criteria.

Anyway, everybody seems to go along and agrees that the Operator Author should be hammered with warnings.

Also, it is important to highlight that:

• The kube-rbac-proxy container scaffold by default via SDK/KB has not these values set
• The container to install the Ansible Operator/manager has not these values set in the default scaffold as well.

So, if we make it fail then, we will start to fail any distribution that is scaffolded by SDK.

IHMO: The argumentation to add the requested resource as mandatory shows strong. But, we can also get started by warning and then, we can revisit this one in the future as well.

c/c @kevinrizza @awgreene @fgiloux

[dmesser]

I thought we had pluggable test suites these days. If so, then making the test fail should not be an issue as long as the user can decide whether or not they want to execute these tests. I agree, not all environments are sensitive to this. LimitRange on the other hand are less ideal, because it requires the user to know what are acceptable values for requests for a Java-based controller vs. a golang-based controller.