-
Spike
-
Resolution: Done
-
Critical
-
None
-
None
-
None
-
BU Product Work
-
False
-
None
-
False
-
OCPSTRAT-996 - Allow internal registry operator to configure a private storage endpoint on Azure
-
-
-
Sprint 235, Sprint 242
We have discussed this back and forth with the installer team, in summary here are the options surfaced in these discussions:
- Installer exposes "Publish" in the infrastructure object
- CIRO consumes this from the "cluster-config" config map, in the kube-system namespace (cluster-config is deprecated)
- Installer configures the registry during cluster provisioning with the "Publish" config
Each of these options has its drawbacks.
Option 1 seems to be the way to go, it would introduce a standard way to consume the publishing status of the cluster. The one thing that could complicate this is that the ingress operator has its own copy of this value - if we introduce a way to consume this, they would probably need to drop that value and use this way of discovery instead.
Option 2's problem is that the cluster-config is deprecated.
Option 3 has the potential challenge of the installer needing to handle cases where CIRO will not be installed in the cluster (can't happen now, but CIRO will be optional in the future). Another potential downside is that the installer becomes aware and needs to configure a component - I'm not sure if we define this is good/standard practice.
OUTCOME
- Create follow-up story in Jira describing the work that needs to be done