Uploaded image for project: 'OpenShift Image Registry'
  1. OpenShift Image Registry
  2. IR-372

Cluster publishing status discovery

XMLWordPrintable

    • Icon: Spike Spike
    • Resolution: Done
    • Icon: Critical Critical
    • openshift-4.15
    • None
    • None
    • None
    • 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:

      1. Installer exposes "Publish" in the infrastructure object
      2. CIRO consumes this from the "cluster-config" config map, in the kube-system namespace (cluster-config is deprecated)
      3. 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

            fmissi Flavian Missi
            fmissi Flavian Missi
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: