-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Relax pod admission controls when using a local catalog index #450
Relax pod admission controls when using a local catalog index #450
Conversation
TestingBefore the change
After the change
|
grpcPodConfig: | ||
securityContextConfig: legacy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏻
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on information provided in STF-1451 I'm approving these changes.
test |
…sion_for_local_catalogs
Copying some context from our OOB discussion... This patch does not affect the production deployment of STF, only the mid-stream integration testing. There are two scenarios currently failing without my new patch. deploy_from_index_enabled - It uses create_catalog.yml to create it's own local CatalogSource deploy_from_bundles_enabled - It uses The problem is that in 4.14, the CatalogSource registry containers don't run in our namespace without the patch. The patch relaxes enforcement to the "baseline" level, same as the openshift-marketplace namespace where all the other CatalogSources live. After a surface investigation, it looks like we should be meeting the requirements for running in the "restricted" profile[1] (without the labels in my patch) so I'm not sure what's going on there. We could likely solve the from_index case by moving the CatalogSource into openshift-marketplace like all the others, but I expect this would be subverting an intent to keep the testing from affecting other namespaces ("real" CatalogSources go in the "real" namespace, but our temporary local-testing CatalogSource stays in our namespace). I don't see a way to do this for the from_bundles case, anyways. In the end, this doesn't even affect the artifacts that we ship, just our testing. We could catch any compliance regressions in STF itself by testing nightly builds from the upstream catalog (where we install the CatalogSource into openshift-marketplace [2]) . My only reservation is that this testing would be more valuable if done on downstream artifacts (where we rely on from_bundles because there is no published catalog), so there is definitely an argument for following up on this.
|
…sion_for_local_catalogs
…sion_for_local_catalogs
…sion_for_local_catalogs
…sion_for_local_catalogs
In terms of CI testing, 8b54a3c passed the 4.12 Jenkins CI gate, proving that this isn't hopelessly broken. The actual code path of the change isn't tested here, only downstream, so now that everything else has turned green I'm going to merge this. |
See https://docs.openshift.com/container-platform/4.13/operators/admin/olm-managing-custom-catalogs.html#olm-catalog-sources-and-psa_olm-managing-custom-catalogs