at the moment, to access private registry, KLM designed it in this way, it expected a selector label oci-registry-cred as ocm resources label. it works now because during module creation, all ocm content will be persisted locally in the moduletemplate including this label. However, in the restricted market, the ocm becomes the single source of truth, if the credentical label persisted inside, it becomes chicken egg problem. We need to have a new soltion for this case.
Proposal
the credentical selector can be a configurable flag in klm, then for different restricted market, the support team can configure it dedicated.
Reasons
Support kyma module deployment in other landscapes.
Acceptance Criteria
[ ] introduce a new flag for klm to allow configure a label selector key value pair, with no default value.
[ ] drop the current support for read oci-registry-cred from ocm resources label
janmedrek
commented
2 weeks ago
at the moment, to access private registry, KLM designed it in this way, it expected a selector label
oci-registry-credas ocm resources label. it works now because during module creation, all ocm content will be persisted locally in the moduletemplate including this label. However, in the restricted market, the ocm becomes the single source of truth, if the credentical label persisted inside, it becomes chicken egg problem. We need to have a new soltion for this case.Proposal
the credentical selector can be a configurable flag in klm, then for different restricted market, the support team can configure it dedicated.
Reasons
Support kyma module deployment in other landscapes.
Acceptance Criteria
oci-registry-credfrom ocm resources labelFeature Testing
Integration tests
Testing approach
have an integration test verify the provided flag can fetch credential secret and verify the content correctly. adapt this existing test if necessary https://github.com/kyma-project/lifecycle-manager/blob/b1fc52d3dd3b167420bc8beaed2b7df07f4c9ffa/tests/integration/controller/manifest/keychain_test.go#L21