anchor.diff:  [discrete]
   ==== Upgrading your cluster
   
  -In {product-title} 3.11, you upgraded your cluster by running Ansible playbooks. In {product-title} 4.5, the cluster manages its own updates, including updates to {op-system-first} on cluster nodes. You can easily upgrade your cluster by using the web console or by using the `oc adm upgrade` command from the OpenShift CLI and the Operators will automatically upgrade themselves. If your {product-title} 4.5 cluster has Red Hat Enterprise Linux worker machines, then you will still need to run an Ansible playbook to upgrade those worker machines.
  +In {product-title} 3.11, you upgraded your cluster by running Ansible playbooks. In {product-title} 4.6, the cluster manages its own updates, including updates to {op-system-first} on cluster nodes. You can easily upgrade your cluster by using the web console or by using the `oc adm upgrade` command from the OpenShift CLI and the Operators will automatically upgrade themselves. If your {product-title} 4.6 cluster has Red Hat Enterprise Linux worker machines, then you will still need to run an Ansible playbook to upgrade those worker machines.
   
   For more information, see xref:../../updating/updating-cluster-between-minor.adoc#updating-cluster-between-minor[Updating clusters].
   
  
positive.code: 
  Configuration for identity providers has changed for {product-title} 4, including the following notable changes:
  
  * The request header identity provider in {product-title} 4.5 requires mutual TLS, where in {product-title} 3.11 it did not.
  * The configuration of the OpenID Connect identity provider was simplified in {product-title} 4.5. It now obtains data, which previously had to specified in {product-title} 3.11, from the provider's `/.well-known/openid-configuration` endpoint.
  
  For more information, see xref:../../authentication/understanding-identity-provider.adoc#understanding-identity-provider[Understanding identity provider configuration].
  
  [id="migration-preparing-monitoring"]
  === Monitoring considerations
  
  Review the following monitoring changes to consider when transitioning from {product-title} 3.11 to {product-title} 4.5.
  
  [discrete]
  ==== Alert for monitoring infrastructure availability
  
negative.code: [discrete]
  ==== Unsupported persistent storage options
  
  Support for the following persistent storage options from {product-title} 3.11 has changed in {product-title} 4.6:
  
  * GlusterFS is no longer supported.
  * CephFS as a standalone product is no longer supported.
  * Ceph RBD as a standalone product is no longer supported.
  
  If you used of one these in {product-title} 3.11, you must choose a different persistent storage option for full support in {product-title} 4.6.
  
  For more information, see xref:../../storage/understanding-persistent-storage.adoc#understanding-persistent-storage[Understanding persistent storage].
  
  [id="migration-preparing-networking"]
  === Networking considerations
  
  Review the following networking changes to consider when transitioning from {product-title} 3.11 to {product-title} 4.6.
  
  [discrete]
  ==== Network isolation mode
  
  The default network isolation mode for {product-title} 3.11 was `ovs-subnet`, though users frequently switched to use `ovn-multitenant`. The default network isolation mode for {product-title} 4.6 is now NetworkPolicy.
  
  If your {product-title} 3.11 cluster used the `ovs-subnet` or `ovs-multitenant` mode, it is recommended to switch to the NetworkPolicy mode for your {product-title} 4.6 cluster. NetworkPolicy is supported upstream, is more flexible, and also provides the functionality that `ovs-multitenant` does. If you want to maintain the `ovs-multitenant` behavior while using NetworkPolicy in {product-title} 4.6, follow the steps to xref:../../networking/configuring-networkpolicy.adoc#nw-networkpolicy-multitenant-isolation_configuring-networkpolicy-plugin[configure multitenant isolation using NetworkPolicy].
  
  For more information, see xref:../../networking/configuring-networkpolicy.adoc#nw-networkpolicy-about_configuring-networkpolicy-plugin[About network policy].
  
  [discrete]
  ==== Encrypting traffic between hosts
  
  In {product-title} 3.11, you could use IPsec to encrypt traffic between hosts. {product-title} 4.6 does not support IPsec. It is recommended to use Red Hat OpenShift Service Mesh to enable mutual TLS between services.
  
  ifndef::openshift-origin[]
  For more information, see xref:../../service_mesh/service_mesh_arch/understanding-ossm.adoc#understanding-ossm[Understanding Red Hat OpenShift Service Mesh].
  