3. What is the nature and description of the request? Today, certain basic images such as `ose-sti-builder`, `ose-deployer`, `ose-builder`, etc. are bound to the version of `atomic-openshift` package installed within Red Hat OpenShift Container Platform Cluster. The list of images related can be found in https://docs.openshift.com/container-platform/3.9/install_config/install/disconnected_install.html#disconnected-syncing-images In case a newer version is required because of a critical bug fix, HOTFIX or security vulnerability (such as https://access.redhat.com/security/vulnerabilities/3422241) the customer is required to update the entire Red Hat OpenShift Container Platform Cluster. This is a massive amount of work and also means a lot of risk (as an upgrade can fail for whatever reason - therefore extensive testing is usually done beforehand). If the version of the mentined images could easily be changed, using sort of configruation option would ease that and give the cusrtomer the ability to only update the image (unless there is a dependency to other updates in Red Hat OpenShift Container Platform). But especially in case of security fixes and HOTFIX this would become really handy and ease the work a lot. 4. Why does the customer need this? (List the business requirements here) Updating the entire Red Hat OpenShift Container Platform is usually a risk for the customer and not something that can be done within 24 hours. So it's time consuming and a task that requires detailed planning. But container images are much easier to manage and it would be simple for the customer to just pull another version of this image for testing, verification purpose or to postpone the Cluster update to a later date time (when testing and verification of the new version finished). For https://access.redhat.com/security/vulnerabilities/3422241 customer is now required to apply an asynchronous update which takes them a lot of time. Having such a functionality would allow them to apply the required patches within minutes rather than days/hours. 5. How would the customer like to achieve this? (List the functional requirements here) With a configruation option for each single image. Base should still be `atomic-openshift` like it is right now. But it should be possible to overwrite the same for every single image using a configuration option in Red Hat OpenShift Container Platform. 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. Either take https://access.redhat.com/security/vulnerabilities/3422241 and check if `ose-sti-builder` can be adjusted on a older Red Hat OpenShift Container Platform version or not. Or else use a HOTFIX or similar to point to a newer version to see if that one is pulled in, instead of the current default. 7. Is there already an existing RFE upstream or in Red Hat Bugzilla? N/A
With the introduction of OpenShift 4, Red Hat has delivered or roadmapped a substantial number of features based on feedback by our customers. Many of the enhancements encompass specific RFEs which have been requested, or deliver a comparable solution to a customer problem, rendering an RFE redundant. This bz (RFE) has been identified as a feature request not yet planned or scheduled for an OpenShift release and is being closed. If this feature is still an active request that needs to be tracked, Red Hat Support can assist in filing a request in the new JIRA RFE system, as well as provide you with updates as the RFE progress within our planning processes. Please open a new support case: https://access.redhat.com/support/cases/#/case/new Opening a New Support Case: https://access.redhat.com/support/cases/#/case/new As the new Jira RFE system is not yet public, Red Hat Support can help answer your questions about your RFEs via the same support case system.