Chapter 1. OpenShift Container Platform 4.7 release notes

OpenShift Container Platform 4.7 includes several improvements to disk provisioning for bare metal deployments. The following features are currently supported for new 4.7 clusters only:

With bootupd, RHCOS users now have access to a cross-distribution, system-agnostic OS update tool that manages firmware and boot updates in UEFI and legacy BIOS boot modes that run on modern architectures.

RHCOS now uses Red Hat Enterprise Linux (RHEL) 8.4 packages in OpenShift Container Platform 4.7.24 and above. This enables you to have the latest fixes, features, and enhancements, such as NetworkManager features, as well as the latest hardware support and driver updates. OpenShift Container Platform 4.6 is an Extended Update Support (EUS) release that will continue to use RHEL 8.2 EUS packages for the entirety of its lifecycle.

The kdump service is introduced in Technology Preview in RHCOS to provide a crash-dumping mechanism for debugging kernel issues. You can use this service to save system memory content for later analysis. The kdump service is not managed at the cluster-level and must be enabled and configured manually on a per-node basis. For more information, see Enabling kdump.

The following Ignition updates are now available:

Previously, RHCOS DHCP kernel parameters were not working as expected because acquiring a DHCP lease would take longer than the default 45 seconds. With this fix, you now have the ability to configure the timeout value that is used when trying to acquire a DHCP lease. See BZ#1879094 for more information.

RHCOS now supports multipath on the primary disk, allowing stronger resilience to hardware failure so that you can set up RHCOS on top of multipath to achieve higher host availability. See BZ#1886229 for more information.

Ignition now supports fetching configs on AWS from Instance Metadata Service Version 2 (IMDSv2). With this enhancement, AWS EC2 instances can be created with IMDSv1 disabled so that IMDSv2 is needed to read the Ignition config from instance userdata. As a result, Ignition successfully reads its config from instance userdata, regardless of whether IMDSv1 is enabled or not. See BZ#1899220 for more information.

The Qemu guest agent is now included by default in RHCOS. With this enhancement, Red Hat Virtualization (RHV) administrators can see rich information about RHCOS nodes through the reporting of useful information about RHCOS back to the RHV management interface. See BZ#1900759 for more information.

You can now install a cluster on Amazon Web Services (AWS) into the Commercial Cloud Services (C2S) Secret Region. Because the C2S region does not have an RHCOS AMI published by Red Hat, you must upload a custom AMI that belongs to that region. You are also required to include the CA certificates for C2S in the additionalTrustBundle field of the install-config.yaml file during cluster installation. Clusters deployed to the C2S Secret Region do not have access to the Internet; therefore, you must configure a private image registry.

The installation program does not support destroying a cluster deployed to the C2S region; you must manually remove the resources of the cluster.

For more information, see AWS government and secret regions.

You can now install a cluster on Google Cloud Platform (GCP) and use a personal encryption key to encrypt both virtual machines and persistent volumes. This is done by setting the controlPlane.platform.gcp.osDisk.encryptionKey, compute.platform.gcp.osDisk.encryptionKey, or gcp.defaultMachinePlatform.osDisk.encryptionKey field in the install-config.yaml file.

You can now install a cluster on your own Red Hat OpenStack Platform (RHOSP) infrastructure that uses bare metal machines. The cluster can have both control plane and compute machines running on bare metal, or just compute machines. For more information, see Deploying a cluster with bare metal machines.

This feature is not supported on clusters that use Kuryr.

The OpenShift Container Platform installer now performs additional validations before attempting to install a cluster on RHOSP. These new validations include:

You can now create compute machines in clusters that run on RHOSP that use a network and subnet of your choice.

Ansible playbooks for installing a cluster on your own RHOSP infrastructure are now packaged for retrieval by using a script in the installation documentation.

You can now enable QEMU Guest Agent support during installation.

You can now configure nodes to have more than 26 persistent Cinder volumes in clusters on RHOSP during installation.

The computeFlavor property that is used in the install-config.yaml file is deprecated. As an alternative, you can now configure machine pool flavors in the platform.openstack.defaultMachinePlatform property.

In previous versions of OpenShift Container Platform, you could not assign a static IP address to the bootstrap host of a bare metal installation that used installer-provisioned infrastructure. Now, you can specify the MAC address that is used by the bootstrap virtual machine, which means you can use static DHCP reservations for the bootstrap host. See BZ#1867165 for more information.

The installer for installer-provisioned installation on bare metal nodes now automatically creates a storage pool for storing relevant data files required during the installation, such as ignition files.

The installer for installer-provisioned installation on bare metal nodes provides a survey which asks the user a minimal set of questions, and generates an install-config.yaml file with reasonable defaults. You can use the generated install-config.yaml file to create the cluster, or edit the file manually before creating the cluster.

Cluster nodes deployed with installer-provisioned installation on bare metal clusters can deploy with static IP addresses. To deploy a cluster so that nodes use static IP addresses, configure a DHCP server to provide infinite leases to cluster nodes. After the installer finishes provisioning each node, a dispatcher script will execute on each provisioned node and convert the DHCP infinite lease to a static IP address using the same static IP address provided by the DHCP server.

If a machine config pool (MCP) is in a degraded state, the Machine Config Operator (MCO) now reports its Upgradeable status as False. As a result, you are now prevented from performing an update within a minor version, for example, from 4.7 to 4.8, until all machine config pools are healthy. Previously, with a degraded machine config pool, the Machine Config Operator did not report its Upgradeable status as false. The update was allowed and would eventually fail when updating the Machine Config Operator because of the degraded machine config pool. There is no change in this behavior for updates within z-stream releases, for example, from 4.7.1 to 4.7.2. As such, you should check the machine config pool status before performing a z-stream update.

The web console is now localized and provides language support for global users. English, Japanese, and Simplified Chinese are currently supported. The displayed language follows your browser preferences, but you can also select a language to override the browser default. From the User drop-down menu, select Language preferences to update your language setting. Localized date and time is now also supported.

A quick start is a guided tutorial with user tasks. In the web console, you can access quick starts under the Help menu. They are especially useful for getting oriented with an application, Operator, or other product offering.

See Creating quick start tutorials in the web console for more information.

The Insights plug-in is now integrated into the OpenShift Container Platform web console. Insights provides cluster health data, such as the number of total issues and total risks of the issues. Risks are labeled as Critical, Important, Moderate, or Low. You can quickly navigate to Red Hat OpenShift Cluster Manager for further details about the issues and how to fix them.

With this release, IBM Z and LinuxONE are now compatible with OpenShift Container Platform 4.7. See Installing a cluster with z/VM on IBM Z and LinuxONE or Installing a cluster with z/VM on IBM Z and LinuxONE in a restricted network for installation instructions.

Notable Enhancements

The following new features are supported on IBM Z and LinuxONE with OpenShift Container Platform 4.7:

Supported features

The following features are also supported on IBM Z and LinuxONE:

Restrictions

Note the following restrictions for OpenShift Container Platform on IBM Z and LinuxONE:

With this release, IBM Power Systems are now compatible with OpenShift Container Platform 4.7. See Installing a cluster on IBM Power Systems or Installing a cluster on IBM Power Systems in a restricted network for installation instructions.

Notable Enhancements

The following new features are supported on IBM Power Systems with OpenShift Container Platform 4.7:

Supported Features

The following features are also supported on IBM Power Systems:

Restrictions

Note the following restrictions for OpenShift Container Platform on IBM Power Systems:

Users can now manage their own OAuth access tokens. This allows users to review their tokens and delete any tokens that have timed out or are no longer needed.

For more information, see Managing user-owned OAuth access tokens.

You can now remove or rotate the GCP admin-level credential that the Cloud Credential Operator uses in Mint mode. This option requires the presence of the admin-level credential during installation, but the credential is not stored in the cluster permanently and does not need to be long-lived.

You can now use the Compliance Operator to perform Center for Internet Security (CIS) Kubernetes Benchmark checks. CIS profiles for OpenShift Container Platform are based on the CIS Kubernetes checks.

Until the CIS OpenShift Container Platform Benchmark is published, you can refer to the Red Hat OpenShift Container Platform Hardening Guide.

You can now deploy a cluster with Secure Boot when using installer-provisioned infrastructure on bare metal nodes. Deploying a cluster with Secure Boot requires UEFI boot mode and Red Fish Virtual Media. You cannot use self-generated keys with Secure Boot.

Red Hat Advanced Cluster Management 2.2 now integrates with the Compliance Operator.

A migration to the OVN-Kubernetes cluster network provider is now supported on installer-provisioned clusters on the following platforms:

To assist you with diagnosing cluster network connectivity issues, the Cluster Network Operator (CNO) now runs a connectivity check controller to perform connection health checks in your cluster. The results of the connection tests are available in PodNetworkConnectivityCheck objects in the openshift-network-diagnostics namespace. For more information, see Verifying connectivity to an endpoint.

When configuring an egress firewall rule, you can now use a DNS domain name instead of an IP address. With the addition of DNS support in the OVN-Kubernetes cluster network provider egress firewall implementation, parity is achieved with the OpenShift SDN cluster network provider egress firewall implementation.

For containers interacting with SR-IOV virtual functions (VFs) in Data Plane Development Kit (DPDK) mode, the app-netutil library now provides the following functions: GetCPUInfo(), GetHugepages(), and GetInterfaces(). For more information, see DPDK library for use with container applications.

The egress router CNI plug-in is introduced in Technology Preview. You can use the plug-in to deploy an egress router in redirect mode. This egress router provides parity for OVN-Kubernetes compared to OpenShift SDN, but for redirect mode only. The plug-in does not perform in HTTP proxy or DNS proxy modes, and this is a difference with the implementation for OpenShift SDN. For more information, see Deploying an egress router pod in redirect mode.

When you install a cluster, you can configure the OVN-Kubernetes cluster network provider with IPsec enabled. With IPsec enabled, all cluster network traffic between pods is sent over an encrypted IPsec tunnel. You cannot enable or disable IPsec after cluster installation.

The IPsec tunnel is not used for network traffic between pods that are configured to use the host network. However, traffic sent from a pod on the host network and received by a pod that uses the cluster network does use the IPsec tunnel. For more information, see IPsec encryption configuration.

The SR-IOV Network Operator is enhanced to support an additional field, spec.nicSelector.netFilter, in the custom resource for an SR-IOV network node policy. You can use the new field to specify an RHOSP network by the network ID. For more information, see Configuring an SR-IOV network device.

Clusters that run on RHOSP and use Kuryr now support services that do not have pod selectors specified.

If legacy applications are sensitive to the capitalization of HTTP header names, use the Ingress Controller spec.httpHeaders.headerNameCaseAdjustments API field for a solution to accommodate legacy applications until they can be fixed.

OpenShift Container Platform will update to HAProxy 2.2, which down-cases HTTP header names by default, for example, changing Host: xyz.com to host: xyz.com. Make sure to add the necessary configuration by using spec.httpHeaders.headerNameCaseAdjustments before upgrading OpenShift Container Platform when HAProxy 2.2 is available.

OpenShift Container Platform 4.7 provides post-installation state-driven network configuration on the secondary network interfaces of cluster nodes using the Kubernetes NMState Operator as a Technology Preview feature. For more information, see Using Kubernetes NMState (Technology Preview).

When using the OpenShift SDN or OVN-Kubernetes cluster network providers, you can select traffic from Ingress Controllers in a network policy rule regardless of whether an Ingress Controller runs on the cluster network or the host network. In a network policy rule, the policy-group.network.openshift.io/ingress="" namespace selector label matches traffic from an Ingress Controller. You can continue to use the network.openshift.io/policy-group: ingress namespace selector label, but this is a legacy label that can be removed in a future release of OpenShift Container Platform.

In earlier releases of OpenShift Container Platform, the following limitations existed:

For more information, refer to About network policy.

When using either the OVN-Kubernetes cluster network provider or the OpenShift SDN cluster network provider, you can use the policy-group.network.openshift.io/host-network: "" namespace selector to select host network traffic in a network policy rule.

You can use the Container Storage Interface (CSI) to create, restore, and delete a volume snapshot when using CSI drivers that provide support for volume snapshots. This feature was previously introduced as a Technology Preview feature in OpenShift Container Platform 4.4 and is now generally available and enabled by default in OpenShift Container Platform 4.7.

For more information, see Using CSI volume snapshots.

The Google Cloud Platform (GCP) persistent disk (PD) CSI driver is automatically deployed and managed on GCP environments, allowing you to dynamically provision these volumes without having to install the driver manually. The GCP PD CSI Driver Operator that manages this driver is in Technology Preview.

For more information, see GCP PD CSI Driver Operator.

You can now use CSI to provision a persistent volume using the CSI driver for OpenStack Cinder.

For more information, see OpenStack Cinder CSI Driver Operator.

The vSphere Problem Detector Operator periodically checks functionality of OpenShift Container Platform clusters installed in a vSphere environment. The vSphere Problem Detector Operator is installed by default by the Cluster Storage Operator, allowing you to quickly identify and troubleshoot common storage issues, such as configuration and permissions, on vSphere clusters.

The Local Storage Operator now includes a must-gather image, allowing you to collect custom resources specific to this Operator for diagnostic purposes. See BZ#1756096 for more information.

The Amazon Web Services (AWS) Elastic File System (EFS) Technology Preview feature has been removed and is no longer supported.

The OpenShift Container Platform internal registry and image streams now support Open Container Initiative (OCI) images. You can use OCI images in the same way you would use Docker schema2 images.

The need to understand if clients are leveraging image stream imports using docker registry v1 protocol resulted in this enhancement, which exports Operator metrics to telemetry. Metrics related to protocol v1 usage are now visible in telemetry. See BZ#1885856 for more information.

To make upgrades more robust, it is recommend that Operators actively communicate with the service that is about to be updated. If a service is processing a critical operation, such as live migrating virtual machines (VMs) in OpenShift Virtualization or restoring a database, it might be unsafe to upgrade the related Operator at that time.

In OpenShift Container Platform 4.7, Operators can take advantage of the new OperatorCondition resource to communicate a non-upgradeable state to Operator Lifecycle Manager (OLM), such as when a related service is performing a critical operation. The non-upgradeable state delays any pending Operator upgrade, whether automatically or manually approved, until the Operator finishes the operation and reports upgrade readiness.

See Operator conditions for more about how OLM uses this communication channel.

See Managing Operator conditions for details on overriding states in OLM as a cluster administrator.

See Enabling Operator conditions for details on updating your project as an Operator developer to use the communication channel.

If certain images relevant to Operators managed by Operator Lifecycle Manager (OLM) are hosted in an authenticated container image registry, also known as a private registry, OLM and OperatorHub are unable to pull the images by default. To enable access, you can create a pull secret that contains the authentication credentials for the registry.

By referencing one or more secrets in a catalog source, some of these required images can be pulled for use in OperatorHub, while other images require updates to the global cluster pull secret or namespace-scoped secrets.

See Accessing images for Operators from private registries for more details.

Cluster administrators can use the oc adm catalog mirror command to mirror the content of an Operator catalog into a container image registry. This enhancement updates the oc adm catalog mirror command to also now mirror the index image being used for the operation into the registry, which was previously a separate step requiring the oc image mirror command. See BZ#1832968 for more information.

Deleting an InstallPlan object that is waiting for user approval causes the Operator to be stuck in an unrecoverable state as the Operator installation cannot be completed. This enhancement updates Operator Lifecycle Manager (OLM) to create a new install plan if the previously pending one is deleted. As a result, users can now approve the new install plan and proceed with the Operator installation. (BZ#1841175)

This enhancement updates the oc adm catalog mirror command to support mirroring images to a disconnected registry by first mirroring the images to local files. For example:

$ oc adm catalog mirror <source_registry>/<repository>/<index_image>:<tag> file:///local/index

Then you can move the local v2/local/index directory to a location within the disconnected network and mirror the local files to the disconnected registry:

$ oc adm catalog mirror file:///v2/local/index <disconnected_registry>/<repository>

See BZ#1841885 for more information.

As of OpenShift Container Platform 4.7, the Operator SDK is now a fully supported Red Hat offering. With the downstream release of Operator SDK v1.3.0, officially supported and branded Operator SDK tooling is now available for download directly from Red Hat.

The Operator SDK CLI assists Operator developers and independent software vendor (ISV) partners in writing Operators that provide a great user experience and are compatible with OpenShift distributions and Operator Lifecycle Manager (OLM).

The Operator SDK enables Operator authors with cluster administrator access to a Kubernetes-based cluster, such as OpenShift Container Platform, to develop their own Operators based on Go, Ansible, or Helm. For Go-based Operators, Kubebuilder is embedded into the SDK as the scaffolding solution; this means existing Kubebuilder projects can be used as is with the SDK and continue to work.

The following features highlight some of the capabilities of the Operator SDK:

See Developing Operators for full documentation on the Operator SDK.

Machine sets running on AWS now support Dedicated Instances. Configure Dedicated Instances by specifying a dedicated tenancy under the providerSpec field in the machine set YAML file.

For more information, see Machine sets that deploy machines as Dedicated Instances.

You can now enable encryption with a customer-managed key for machine sets running on GCP. Users can configure an encryption key under the providerSpec field in the machine set YAML file. The key is used to encrypt the data encryption key, not to encrypt the customer’s data.

For more information, see Enabling customer-managed encryption keys for a machine set.

The Machine API now honors cluster-wide proxy settings. When a cluster-wide proxy is configured, all Machine API components will route traffic through the configured proxy.

The Machine Config Operator (MCO) no longer automatically reboots all corresponding nodes for the following machine configuration changes:

For more information, see Understanding the Machine Config Operator.

In OpenShift Container Platform 4.6, when the online flag in the BareMetalHost API is set to false, the Bare Metal Operator shuts down nodes "hard." That is, it turns the power off without giving the operating system or workloads time to react. In OpenShift Container Platform 4.7 and subsequent releases, the API sends the node’s operating system a signal telling it to shut down, and then waits for the node to power off in "soft" mode. If the operating system does not shut down the node within three minutes, the Bare Metal Operator executes a "hard" shutdown.

OpenShift Container Platform 4.8 will execute a "hard" shutdown for remediation purposes, such as if there is a known problem with the node. The behavior of executing a "hard" shutdown for remediation purposes will be back ported to OpenShift Container Platform 4.7.

The machine health resource example described in About machine health checks has been updated with a shorter health check timer value.

Starting with OpenShift Container Platform 4.7, during power-based remediation if the power operations do not complete successfully, the bare-metal machine controller triggers the reprovisioning of the unhealthy node. The exception to this is if the node is a master node or a node that was provisioned externally.

When provisioning a new node in the cluster, if the MAC address of an existing bare-metal node in the cluster matches the MAC address of a bare-metal host you are attempting to add to the cluster, the installation fails and a registration error is displayed for the failed bare-metal host.

You can diagnose a duplicate MAC address by examining the bare-metal hosts that are running in the openshift-machine-api namespace.

For more information, see Diagnosing a duplicate MAC address when provisioning a new host in the cluster.

The descheduler is now generally available. The descheduler provides the ability to evict a running pod so that the pod can be rescheduled onto a more suitable node. You can enable one or more of the following descheduler profiles:

For more information, see Evicting pods using the descheduler.

You can now specify a scheduler profile to control how pods are scheduled onto nodes. This is a replacement for configuring a scheduler policy. The following scheduler profiles are available:

For more information, see Scheduling pods using a scheduler profile.

Autoscaling for memory utilization is now generally available. You can create horizontal pod autoscaler custom resources to automatically scale the pods associated with a deployment config or replication controller to maintain the average memory utilization you specify, either a direct value or a percentage of requested memory. For more information, see Creating a horizontal pod autoscaler object for memory utilization.

Clusters that run on RHOSP can now autoscale to zero machines.

You can now configure a priority class to be non-preempting by setting the preemptionPolicy field to Never. Pods with this priority class setting are placed in the scheduling queue ahead of lower priority pods, but do not preempt other pods.

For more information, see Non-preempting priority classes.

CRI-O now supports specifying CPUs for node host processes (such as kubelet, CRI-O, and so forth). Using the infra_ctr_cpuset parameter in the crio.conf file allows you to reserve CPUs for the node host processes allowing OpenShift Container Platform pods that require guaranteed CPUs to operate without any other processes running on those CPUs. Pods that request guaranteed CPUs do not have to compete for CPU time with the node host process. See BZ#1775444 for more information.

OpenShift Container Platform 4.7 includes the following alerting rule changes:

OpenShift Container Platform 4.7 includes version updates to the following monitoring stack components and dependencies:

Modifying Alertmanager configurations by using the AlertmanagerConfig custom resource definition (CRD) in the Prometheus Operator is not supported.

For more information, see Support considerations for monitoring.

The API Performance dashboard is now available from the web console. This dashboard can be used to help troubleshoot performance issues with the Kubernetes API server or the OpenShift API server. You can access the API Performance dashboard from the web console in the Administrator perspective by navigating to Monitoring Dashboards and selecting the API Performance dashboard.

This dashboard provides API server metrics, such as:

The Namespace (Pods) and Pod Kubernetes networking dashboards are now enabled in Grafana. You can access the Namespace (Pods) and Pod dashboards from the web console in the Administrator perspective by navigating to Monitoring Dashboards Grafana UI.

These dashboards provide networking metrics, such as:

HWMon data collection is enabled for hardware health telemetry such as CPU temperature and fan speeds for bare metal clusters.

You can now configure the Thanos Querier logLevel field for purposes such as debugging.

The memory limit was removed on the config-reloader container in the openshift-user-workload-monitoring namespace for Prometheus and Thanos Ruler pods. This update prevents OOM kill of the config-reloader container, which previously occurred when the container used more memory than the defined limit.

The previous Technology Preview configuration that enabled users to monitor their own services is now removed and not supported in OpenShift Container Platform 4.7. The techPreviewUserWorkload field is removed from the cluster-monitoring-config ConfigMap object and is no longer supported.

See Monitoring overview for more information on monitoring user defined projects.

Updated guidance around cluster maximums for OpenShift Container Platform 4.7 is now available.

Use the OpenShift Container Platform Limit Calculator to estimate cluster limits for your environment.

OpenShift Container Platform 4.7 supports the OpenNESS SR-IOV Operator for Wireless FEC Accelerators.

This Operator supports the requirements of vRAN deployments for low power, cost, and latency, while also delivering the capacity to manage spikes in performance for a range of use cases. One of the most compute-intensive 4G and 5G workloads is RAN layer 1 (L1) forward error correction (FEC), which resolves data transmission errors over unreliable or noisy communication channels.

Delivering high performance FEC is critical to 5G maintaining high performance as it matures and as more users depend on the network. FEC is now supported on the Intel vRAN Dedicated Accelerator ACC100 card with the OpenNESS SR-IOV Operator for Wireless FEC Accelerator.

For more information, see Optimizing data plane performance with the Intel vRAN Dedicated Accelerator ACC100.

The latency test, a part of the CNF-test container, provides a way to measure if the isolated CPU latency is below the requested upper bound.

For information about running a latency test, see Running the latency tests.

The Performance Addon Operator manages host CPUs by dividing them into reserved CPUs for cluster and operating system housekeeping duties, and isolated CPUs for workloads. A new performance profile field globallyDisableIrqLoadBalancing is available to manage whether or not device interrupts are processed by the isolated CPU set.

New pod annotations irq-load-balancing.crio.io and cpu-quota.crio.io are used in conjunction with globallyDisableIrqLoadBalancing to define whether or not device interrupts are processed for a pod. When configured, CRI-O disables device interrupts only as long as the pod is running.

For more information, see Managing device interrupt processing for guaranteed pod isolated CPUs.

A new VRF CNI plugin that allows you to assign additional networks to a VRF is now available. When you create a secondary network using a rawConfig configuration for the CNO custom resource and configure a VRF for it, the interface created for the pod is associated with the VRF. You can also use the VRF CNI plug-in to assign an SR-IOV network to a VRF.

For more information, see Assigning a secondary network to a VRF and Assigning an SR-IOV network to a VRF.

xt_u32 is an iptables kernel module that allows packet filtering based on arbitrary content. It can look beyond headers or special protocols that are not covered by other iptables modules.

For more information, see Performing end-to-end tests for platform verification.

In OpenShift Container Platform 4.7, the Insights Operator collects the following additional information:

With this additional information, Red Hat can provide improved remediation steps in Red Hat OpenShift Cluster Manager.

You can now configure the Cloud Credential Operator (CCO) to use the Amazon Web Services Security Token Service (AWS STS). When the CCO is configured to use STS, it assigns components IAM roles that provide short-term, limited-privilege security credentials.

For more information, see Support for Amazon Web Services Secure Token Service (AWS STS).

Power-based remediation for bare metal, which is installed using installer provisioned infrastructure (IPI), is now available. You can configure MachineHealthCheck CRs to trigger power-based remediation that power-cycles instead of reprovisioning the node.

This remediation significantly reduces the time to recover stateful workloads and compute capacity in bare metal environments. For more information, see About power-based remediation of bare metal.

Using a scheduler policy to control pod placement is deprecated and is planned for removal in a future release. For more information on the Technology Preview alternative, see Scheduling pods using a scheduler profile.

When using the oc adm catalog mirror command to mirror catalogs, the --filter-by-os flag was previously allowed to filter architectures of mirrored content. This would break references to those images in the catalog that point to the manifest list and not the manifest. The --filter-by-os flag now only filters the index image that is pulled and unpacked. To clarify this, the new --index-filter-by-os flag is now added and should be used instead.

The --filter-by-os flag is also now deprecated.

Image stream image imports are no longer tracked in real time by conditions on the Cluster Samples Operator configuration resource. In-progress image streams no longer directly affect updates to the ClusterOperator instance openshift-samples. Prolonged errors with image streams are now reported by Prometheus alerts.

Upgrade tracking is now achieved by the other conditions and both the individual image stream config maps and the imagestream-to-image config map.

Currently, oc fixes apiVersion in YAML or JSON resource files OpenShift Container Platform resources from v1 to the correct value for the object. For example, v1 is corrected to apps.openshift.io/v1 for DeploymentConfig objects. This behavior is deprecated and is planned for removal in a future release, and every resource that includes *.openshift.io must match the apiVersion value found in the API index.

This release adds a warning that displays the correct value of apiVersion when it is missing from an object.

Using non-groupfied API resources is deprecated and will be removed in a future release, update apiVersion to "apps.openshift.io/v1" for your resource

When you encounter this message, update your resource file to use the correct value.

The instance_type_id installation configuration parameter is deprecated and will be removed in a future release.

When using installer-provisioned installation on bare metal nodes, OpenShift Container Platform 4.6 required providing two IP addresses from the baremetal network to the provisioningHostIP and bootstrapProvisioningIP configuration settings when deploying without a provisioning network. These IP addresses and configuration settings are no longer required in OpenShift Container Platform 4.7 when using installer provisioned infrastructure on bare metal nodes and deploying without a provisioning network.

The following images are no longer included in the samples imagestreams provided with OpenShift Container Platform:

registry.redhat.io/ubi8/go-toolset:1.13.4
registry.redhat.io/rhdm-7/rhdm-decisioncentral-rhel8:7.8.1
registry.redhat.io/rhdm-7/rhdm-decisioncentral-rhel8:7.8.0
registry.redhat.io/rhdm-7/rhdm-kieserver-rhel8:7.8.1
registry.redhat.io/rhdm-7/rhdm-kieserver-rhel8:7.8.0
registry.redhat.io/rhpam-7/rhpam-businesscentral-monitoring-rhel8:7.8.1
registry.redhat.io/rhpam-7/rhpam-businesscentral-monitoring-rhel8:7.8.0
registry.redhat.io/rhpam-7/rhpam-businesscentral-rhel8:7.8.0
registry.redhat.io/rhpam-7/rhpam-kieserver-rhel8:7.8.1
registry.redhat.io/rhpam-7/rhpam-kieserver-rhel8:7.8.0
registry.redhat.io/rhpam-7/rhpam-smartrouter-rhel8:7.8.1
registry.redhat.io/rhpam-7/rhpam-smartrouter-rhel8:7.8.0

With this release, the following items that are used with oc are removed:

The Amazon Web Services (AWS) Elastic File System (EFS) Technology Preview feature has been removed and is no longer supported.

Starting with OpenShift Container Platform 4.7.47, support for using the Cloud Credential Operator (CCO) in mint mode on Microsoft Azure clusters has been removed from OpenShift Container Platform 4.7. This change is due to the planned retirement of the Azure AD Graph API by Microsoft on 30 June 2022 and is being backported to all supported versions of OpenShift Container Platform in z-stream updates.

For previously installed Azure clusters that use mint mode, the CCO attempts to update existing secrets. If a secret contains the credentials of previously minted app registration service principals, it is updated with the contents of the secret in kube-system/azure-credentials. This behavior is similar to passthrough mode.

For clusters with the credentials mode set to its default value of "", the updated CCO automatically changes from operating in mint mode to operating in passthrough mode. If your cluster has the credentials mode explicitly set to mint mode ("Mint"), you must change the value to "" or "Passthrough".

While the Azure AD Graph API is still available, the CCO in upgraded versions of OpenShift Container Platform attempts to clean up previously minted app registration service principals. Upgrading your cluster before the Azure AD Graph API is retired might avoid the need to clean up resources manually.

If the cluster is upgraded to a version of OpenShift Container Platform that no longer supports mint mode after the Azure AD Graph API is retired, the CCO sets an OrphanedCloudResource condition on the associated CredentialsRequest but does not treat the error as fatal. The condition includes a message similar to unable to clean up App Registration / Service Principal: <app_registration_name>. Cleanup after the Azure AD Graph API is retired requires manual intervention using the Azure CLI tool or the Azure web console to remove any remaining app registration service principals.

To clean up resources manually, you must find and delete the affected resources.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To upgrade an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

This update contains changes from Kubernetes 1.20.11. More information can be found in the following changelog: 1.20.11.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

Starting with OpenShift Container Platform 4.7.47, support for using the Cloud Credential Operator (CCO) in mint mode on Microsoft Azure clusters has been removed from OpenShift Container Platform 4.7. This change is due to the planned retirement of the Azure AD Graph API by Microsoft on 30 June 2022 and is being backported to all supported versions of OpenShift Container Platform in z-stream updates. For more information, see Support for minting credentials for Microsoft Azure removed.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.7 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.