OCPBUGS-17791: CatalogSource: update GoDoc

[stevekuznetsov]

We won't be setting a memory limit, so udpate the doc.

Impl: operator-framework/operator-lifecycle-manager#3015

[codecov]

Codecov Report

Merging #291 (0f058f5) into master (775e6c6) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #291   +/-   ##
=======================================
  Coverage   42.11%   42.11%           
=======================================
  Files          39       39           
  Lines        3495     3495           
=======================================
  Hits         1472     1472           
  Misses       1877     1877           
  Partials      146      146           

Files Changed	Coverage Δ
crds/zz_defs.go	35.84% <ø> (ø)
pkg/operators/v1alpha1/catalogsource_types.go	57.69% <ø> (ø)

[perdasilva]

Lgtm

[awgreene]

/hold
Before we proceed with merging this PR, I want to have a conversation on the backwards incompatible change it introduces. From the related OLM PR, it seems like we're introducing this API change to meet an OpenShift core payload requirement. While some catalogSources are defaults on cluster, users can and do create their own catalogSources.

Are we certain that these API changes won't impact existing user workflows on custom catalogSources? IIRC:

• a pod that exceeds it's memory limit will be killed.
• Memory granted to pods isn't yielded back even if the pod doesn't actively need the memory (For example, if the pod needs a bunch of memory at startup it won't abandon it later even if it requires less resources).

So if a user had been using this field, the pod would crash loop assuming that it always requires the same memory that initially caused the crash. If this is the case, I don't see much value in the existing behavior and would be comfortable merging this.

[stevekuznetsov]

So if a user had been using this field

The field has never been published, so it's not possible for anyone to have been using it.

Are we certain that these API changes won't impact existing user workflows on custom catalogSources?

Yes, as you note the only change here is that a pod that was crash-looping would no longer be.

[awgreene]

Thanks @stevekuznetsov
/unhold

[awgreene]

/approve
/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: awgreene, stevekuznetsov

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 [awgreene]

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