Bug 1711070 - Set container resource requests

[kevinrizza]

• Set container resource requests for operator deployment
• Set container resource requests for registry pod deployments

https://bugzilla.redhat.com/show_bug.cgi?id=1711070

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kevinrizza

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [kevinrizza]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kevinrizza]

/hold

[kevinrizza]

Putting a hold on this pr while I wait for a response regarding the magic numbers for these resource limits:

https://bugzilla.redhat.com/show_bug.cgi?id=1711070#c7

[ecordell]

@kevinrizza What do you think of this plan:

Pick requests for marketplace-operator:

• Something around what current cpu usage is
• Breathing room for memory request, maybe 120% of what current memory usage is with the default operatorsources

Pick a default request for the registry pods that marketplace spins up:

• Something around what current cpu usage is
• Breathing room for memory request, maybe 120% of whatever the max is for one of the default registry pods.

Then, in the future, we can:

• remove the appregistry caching from marketplace-operator, which will make its memory relatively static (and lower than tody)
• remove actual content storage from operator-registry, so that size doesn't fluctuate as much and we can have some reasonable defaults

Having any values for resource requests are better than what we have today, and we can continue to refine over time. Right now the scheduler doesn't know anything about these pods.

[kevinrizza]

@kevinrizza What do you think of this plan:

Pick requests for marketplace-operator:

• Something around what current cpu usage is
• Breathing room for memory request, maybe 120% of what current memory usage is with the default operatorsources

Pick a default request for the registry pods that marketplace spins up:

• Something around what current cpu usage is
• Breathing room for memory request, maybe 120% of whatever the max is for one of the default registry pods.

Then, in the future, we can:

• remove the appregistry caching from marketplace-operator, which will make its memory relatively static (and lower than tody)
• remove actual content storage from operator-registry, so that size doesn't fluctuate as much and we can have some reasonable defaults

Having any values for resource requests are better than what we have today, and we can continue to refine over time. Right now the scheduler doesn't know anything about these pods.

This makes sense to me for now. I did some cursory memory testing with a cluster in AWS and set these defaults:

50mi for the operator deployment
100mi for all registry deployments

I updated the pr accordingly. @ecordell @tkashem @awgreene Please review.

[kevinrizza]

/hold cancel

[ecordell]

@kevinrizza could you do a quick rebase on this?

[ecordell]

/lgtm
/retest

[kevinrizza]

@ecordell had to rebase this one after changes were made to the manifests, can I get another lgtm?

[kevinrizza]

/retest

[kevinrizza]

/test e2e-aws-upgrade

[ecordell]

/lgtm