Background:

OKD has historically tracked the latest OS release for a given OCP / OKD release. In other words, OKD on SCOS (CentOS Stream CoreOS) has been running Stream 10 for quite some time and once Stream 11 is available, OKD will make the switch at the next y release. This differs from the paradigm that dualstream enables for OCP where we intend to enable dualstream for both RHEL 9 and RHEL 10 and eventually RHEL 10 and RHEL 11. Consequently, since OKD has historically been "single stream", there is likely no need for dualstream support since dualstream is an internal OCP feature. But that doesn't mean that OKD should be completely ignored. Instead, we need to be sure that OKD is compatible with dualstream, even if it will never be able to use that feature.

In terms of ensuring that the feature will not be active, OKD now has its own FeatureSet which does not include dualstream. This means that the MCO will not attempt to create / manage OSImageStream objects in an OKD cluster because that FeatureGate simply cannot be enabled there. Additionally, care was taken to put the dualstream work within the operator behind a Go build tag that excludes OKD.

Finally, there is a proposal for creating a single OSImageStream tuple for OKD that only includes the current SCOS image for that release. The intention behind this is to ensure that OKD is compatible with the parts of the system that rely upon OSImageStreams without supporting multiple streams. 

Open Questions:

• What is the interaction between OSImageStreams and other MCO objects such as MachineConfigPools (MCP)?
• Will those interactions become critical to the MCOs function and its various features such as Image Mode OpenShift?
• Would OKD need a single OSImageStream tuple in order for the aforementioned interactions to work?
• Other than FeatureGates, is there a reasonable pattern for segregating OCP-specific vs OKD-specific behaviors such as using Go build tags? Is it necessary for us to do this?
• The RenderController is what allows a cluster admin to switch between OSImageStreams. Would it make sense to do a similar exclusion with build tags like was done for the operator to ensure that this behavior is excluded from OKD?

Done When:

• All of the above questions have been answered.
• Documentation and / or proof-of-concept code has been produced.
• Future work for dualstream is defined based upon the answers to those questions.