From 59225888e8ff5d6b2f7c642f4c69506dddf8f844 Mon Sep 17 00:00:00 2001 From: Ashley Hardin Date: Tue, 27 Aug 2019 15:32:11 -0400 Subject: [PATCH] Added 4.2 release notes --- _topic_map.yml | 4 +- release_notes/ocp-4-2-release-notes.adoc | 1013 ++++++++++++++++++++++ release_notes/versioning-policy.adoc | 4 +- welcome/index.adoc | 2 +- 4 files changed, 1018 insertions(+), 5 deletions(-) create mode 100644 release_notes/ocp-4-2-release-notes.adoc diff --git a/_topic_map.yml b/_topic_map.yml index a5388eb9e634..6a3b702ae4bf 100644 --- a/_topic_map.yml +++ b/_topic_map.yml @@ -41,8 +41,8 @@ Name: Release notes Dir: release_notes Distros: openshift-enterprise Topics: -- Name: OpenShift Container Platform 4.1 release notes - File: ocp-4-1-release-notes +- Name: OpenShift Container Platform 4.2 release notes + File: ocp-4-2-release-notes - Name: Versioning policy File: versioning-policy --- diff --git a/release_notes/ocp-4-2-release-notes.adoc b/release_notes/ocp-4-2-release-notes.adoc new file mode 100644 index 000000000000..d706fa3334a1 --- /dev/null +++ b/release_notes/ocp-4-2-release-notes.adoc @@ -0,0 +1,1013 @@ +[id="ocp-4-2-release-notes"] += {product-title} 4.2 release notes +include::modules/common-attributes.adoc[] +:context: release-notes + +toc::[] + +Red Hat {product-title} provides developers and IT organizations with a hybrid +cloud application platform for deploying both new and existing applications on +secure, scalable resources with minimal configuration and management overhead. +{product-title} supports a wide selection of programming languages and +frameworks, such as Java, JavaScript, Python, Ruby, and PHP. + +Built on Red Hat Enterprise Linux and Kubernetes, {product-title} +provides a more secure and scalable multi-tenant operating system for today’s +enterprise-class applications, while delivering integrated application runtimes +and libraries. {product-title} enables organizations to meet security, privacy, +compliance, and governance requirements. + +[id="ocp-4-2-about-this-release"] +== About this release + +Red Hat {product-title} +(link:https://access.redhat.com/errata/RHBA-2019:2921[RHBA-2019:2921]) is now +available. This release uses Kubernetes 1.14 with CRI-O runtime. New features, +changes, and known issues that pertain to {product-title} {product-version} are +included in this topic. + +{product-title} {product-version} clusters are available at +https://cloud.openshift.com/openshift. The Red Hat OpenShift Cluster Manager +application for {product-title} allows you to deploy OpenShift clusters to +either on-premise or cloud environments. + +{product-title} {product-version} is supported on Red Hat Enterprise Linux 7.6 and +later, as well as Red Hat Enterprise Linux CoreOS 4.1. + +You must use {op-system-first} for the control plane, or master, machines and +can use either {op-system} or Red Hat Enterprise Linux 7.6 for compute, or worker, +machines. + +[IMPORTANT] +==== +Because only Red Hat Enterprise Linux version 7.6 is supported for compute +machines, you must not upgrade the Red Hat Enterprise Linux compute machines to +version 8. +==== + +[id="ocp-4-2-new-features-and-enhancements"] +== New features and enhancements + +This release adds improvements related to the following components and concepts. + +[id="ocp-4-2-installation-and-upgrade"] +=== Installation and upgrade + +[id="ocp-4-2-migrations"] +==== Migrations + +Tooling and advice for moving from {product-title} 3.x to 4.x is now available. + +[id="ocp-4-2-openshift-install"] +==== CLI-based installation + +{product-title} {product-version} introduces a new CLI-based installer called +`openshift-install`. It is designed to simplify provisioning OpenShift on +immutable installer provisioned infrastructure using an interactive guided +workflow within about 30 minutes. This approach provides an OpenShift deployment +with full stack automation of host OS and platform updates and infrastructure +management without the complexity of having to provision your own +infrastructure. Only minimal user input is needed with all non-essential +installation configuration options, which are now configured post-installation +via component operator Custom Resource Definitions (CRDs). + +Updates are performed largely the same way. OpenShift update content must be +mirrored first to the local container registry first then the administrator +tells `oc adm upgrade` where to pull the update content from. + +[id="ocp-4-2-installations-in-restricted-networks"] +==== Installations in restricted networks + +{product-title} {product-version} introduces support for installation and +updating {product-title} clusters in restricted network environments. It is +designed to work with any `docker` 2.2 spec-compliant container registry for +hosting {product-title} content. + +Administrators first must replicate content from Quay.io to their local +container registry. After that is done, `openshift-install` can be configured to +generate Ignition configs that pull content locally rather than from Quay.io. +This is designed to work with user-provisioned infrastructure (UPI) deployments +only. + +You can still use Operators from the OLM catalog in restricted networks. +However, you must manually pull the Operator sources in order to populate the +the offline catalog. This manual process is only a temporary workaround for +{product-title} {product-version}. An automated solution will be provided in a +future release. + +See +xref:../installing/installing_restricted_networks/installing-restricted-networks-preparations.adoc#installing-restricted-networks-preparations[Installing in restricted networks] +and xref:../applications/operators/olm-disconnected.adoc#olm-disconnected[Using Operator Lifecycle Manager on restricted networks] +for details. + +[id="ocp-4-2-cluster-wide-egresss-proxy"] +==== Cluster-wide egress proxy + +{product-title} {product-version} introduces support for installing and updating +an OpenShift cluster through a corporate proxy server. Proxy information +(httpProxy, httpsProxy, and noProxy) can be defined in `install-config`, which +is used during the installation process and can also be managed +post-installation via the cluster proxy object. + +Also, there is now support for providing your own CA bundles allowing the +corporate proxy to MITM HTTPS. + +[id="ocp-4-2-new-platform-boundary"] +==== New platform boundary + +{product-title} is now aware of the entire infrastructure and brings the +operating system under management. This makes installation and updates seamless +across the platform and the underlying operating system. Everything is managed +as a single entity. + +[id="ocp-4-2-IPI-UPI"] +==== IPI and UPI + +In {product-title} {product-version}, there are two primary installation +experiences: Full stack automation (IPI) and pre-existing infrastructure (UPI). + +With full stack automation, the installer controls all areas of the installation +including infrastructure provisioning with an opinionated best practices +deployment of {product-title}. With re-existing infrastructure deployments, +administrators are responsible for creating and managing their own +infrastructure allowing greater customization and operational flexibility. + +[id="ocp-4-2-full-stack-automated-deployments"] +==== Full stack automated deployments + +In {product-title} {product-version}, there is expanded support for full stack +automated deployments to include AWS, Microsoft Azure, Google Cloud Platform (GCP), +and Red Hat OpenStack Platform, as well as adding GCP to the existing list of +user provisioned infrastructure supported providers that already includes AWS, +Bare Metal, and VMware vSphere. + +[id="ocp-4-2-operators"] +=== Operators + +[id="ocp-4-2-scoped-operator-installations"] +==== Scoped Operator installations + +Previously, only users carrying `cluster-admin` roles were allowed to install +Operators. In {product-title} 4.2, the `cluster-admin` can select namespaces in +which namespace administrators can install Operators self-sufficiently. The +`cluster-admin` defines the ServiceAccount in this namespace; all installed +Operators in this namespace get equal or lower permissions of this +ServiceAccount. + +See +xref:../applications/operators/olm-creating-policy.adoc#olm-creating-policy[Creating policy for Operator installations and upgrades] +for details. + +[id="ocp-4-2-ingress-operator"] +==== Ingress Operator +The Ingress Operator supports all ingress features on {product-version} with +installer-provisioned infrastructure on Azure and GCP. + +[id="ocp-4-2-machine-config-operator"] +==== Machine Config Operator + +The Machine Config Operator (MCO) provides cluster-level configuration, enables +rolling upgrades, and prevents drift between new and existing nodes. + +[id="ocp-4-2-node-feature-discovery-operator"] +==== Node Feature Discovery Operator + +The Node Feature Discovery (NFD) Operator detects hardware features available +on each node and advertises those features using node labels. + +CPU features managed by NFD include: + +* cpuid +* hardware_multithreading +* power +* pstate + +Kernel features managed by NFD include: +* config +* selinux_enabled +* version +* os_version + +Other features managed by NFD include: + +* NVMe +* NUMA +* SR-IOV +* GPUs + +The NFD Operator manages the installation and lifecycle of the NFD DaemonSet. +Access the NFD Operator in OperatorHub. + +[id="ocp-4-2-node-tuning-operator-enhancements"] +==== Node Tuning Operator enhancements + +The Node Turning Operator was first introduced in {product-title} 4.1 and +manages cluster node-level tuning; The default CR is meant for delivering +standard node-level tuning. The enhancements in {product-title} +{product-version} allow for customizing the tunings for things such as high +performance. + +For custom tuning, create your own tuned custom resources (CRs). Newly created +CRs will be combined with the default CR and custom tuning applied to nodes +based on node or pod labels and profile priorities. + +[id="ocp-4-2-storage"] +=== Storage + +[id="ocp-4-2-persistent-volumes-LSO"] +==== Persistent volumes using the Local Storage Operator + +Persistent volumes using the Local Storage Operator is now available in +{product-title} {product-version}. + +[id="ocp-4-2-OCS"] +==== OpenShift Container Storage 4.2 + +With {product-title} {product-version}, OpenShift Container Storage (OCS) 4.2 is +available, providing persistent storage for applications and {product-title} +infrastructure services. OCS 4.2 will provide complete data services for +{product-title}, including dynamic provisioning of object buckets. This S3 +capability is new in OCS 4.2. A consistent S3 interface is now added across +public and on-premise infrastructure. + +[id="ocp-4-2-CSI"] +==== OpenShift Container Storage Interface (CSI) + +Container Storage Interface (CSI) is now available in {product-title} +{product-version}. CSI is introduced in Kubernetes to enable Red Hat OpenShift +Container Storage (OCS) and partners with their CSI plug-ins. With the adoption +of the CSI, the Kubernetes volume layer becomes truly +link:https://kubernetes.io/blog/2018/04/10/container-storage-interface-beta/[extensible]. + +For now, only the API is available. CSI drivers contained in operators will be +available in future releases. + +[id="ocp-4-2-storage-devices"] +==== Storage devices + +The Cluster Storage Operator sets up the default storage class. It looks through +the cloud provider and sets up the correct storage class. + +Raw Block with iSCSI is now in xref:ocp-4-2-technology-preview[Technology Preview]. + +New storage devices are supported in {product-title} {product-version}: + +* Raw block with local Volumes +* Raw block with cloud providers (AWS, GCP, Azure, and vSphere) + +[id="ocp-4-2-scale"] +=== Scale + +[id="ocp-4-2-scale-cluster-limits"] +==== Cluster limits + +Updated guidance around +xref:../scalability_and_performance/planning-your-environment-according-to-object-limits.adoc#planning-your-environment-according-to-object-limits[Cluster +Limits] for {product-title} {product-version} is now available. + +Use the link:https://access.redhat.com/labs/ocplimitscalculator/[{product-title} +Limit Calculator] to estimate cluster limits for your environment. + +[id="ocp-4-2-developer-experience"] +=== Developer experience + +[id="ocp-4-2-ODO"] +==== OpenShift Do + +OpenShift Do (ODO) is a CLI tool for developers to create, build, and deploy +applications on OpenShift. ODO is completely client based and requires no server +within the {product-title} cluster for deployment. It detects changes to local +code and deploys it to the cluster automatically, giving instant feedback to +validate changes in real time. It supports multiple languages and frameworks. + +[id="ocp-4-2-nodes"] +=== Nodes + +[id="ocp-4-2-crio-support"] +==== CRI-O support + +CRI-O is a kubernetes-specific container engine that tracks and versions +identical to Kubernetes, simplifying support permutations. Adoption is trivial +because all existing Docker and OCI containers are supported and run well with +CRI-O. CRI-O is a light weight, kubernetes-native, OCI-compatible container +runtime that is life-cycled and managed by {product-title}. You do not need to +worry about which container runtime is in use. With {product-title}, it is +always the right one and it provide a complete implementation of the Kubernetes +Container Runtime Interface (CRI). Also, you do not need to separately manage +the container engine. CRI-O has some tuneables that provide control and security +for CRI-O; they are easily configured in a CRD, and the settings are propagated +across the cluster. + +[id="ocp-4-2-whitelisting-of-sysctls"] +==== Whitelisting of sysctls configuration + +System administrators can whitelist sysctl on a per-node basis. All safe sysctls +are enabled by default; all unsafe sysctls are disabled by default.See +xref:../nodes/containers/nodes-containers-sysctls.adoc#nodes-containers-sysctls[Using +sysctls in containers] for more information. + +[id="ocp-4-2-master-nodes-schedulable"] +==== Master nodes are now schedulable + +In {product-title} {product-version}, master nodes are schedulable. See +xref:../nodes/nodes/nodes-nodes-working.adoc[Working with nodes] for more +information. + +[id="ocp-4-2-networking"] +=== Networking + +==== Installer-provisioned OpenShift on OpenStack + +{product-title} {product-version} introduces full-stack automation support for +deploying {product-title} clusters on Red Hat OpenStack. + +The installer uses the OpenStack APIs in conjunction with the Kubernetes +OpenStack Cloud Provider to create all the required OpenStack resources, such as +virtual machines (VMs), networks, security groups, and object storage needed to +deploy {product-title} and properly configure the cluster to run on the Red Hat +OpenStack Platform. + +{product-title} {product-version} can be deployed on Red Hat OpenStack version +13. + +Kuryr exists to improve the network performance of pods when running workloads +on Red Hat OpenStack. Kuryr is an SDN solution combining a Kubernetes CNI plug-in +(kuryr-kubernetes) and OpenStack Neutron to provide interconnectivity between +Kubernetes pods and OpenStack virtual instances. + +[id="ocp-4-2-OVN"] +==== OVN (Technology Preview) + +Open Virtual Networking (OVN) for Open vSwitch, currently in +xref:ocp-4-2-technology-preview[Technology Preview], has many advantages, +including acceleration of customer-driven feature requirements, some of which +are pre-enabled, including: + +* Low barrier to integration; an implementation of virtual networking via OVS. +* SDN portfolio consolidation. +* Virtually eliminate iptables scale issues. +* Heterogeneous Linux/Windows clusters. +* The ability to have a cluster network that spans on-premise nodes and cloud +nodes. +* Full Network Policy support. +* Egress IP per pod. +* Distributed L4 Ingress/Egress firewall. +* Distributed services load balancer. +* Heterogeneous clusters with Windows nodes +* The capability to span on-premise and cloud nodes. +* Traffic isolation and multi-tenancy. +* Data Plane Development Kit (DPDK) support. +* Encrypted tunnels. +* IPv6 and DHCPv6. +* QoS, control and data plane separation. + +[id="ocp-4-2-enable-ingress-controllers"] +==== Enable internal Ingress Controllers for private clusters + +When creating an Ingress Controller on cloud platforms, the Ingress Controller is +published by a public cloud load balancer by default. + +Users can now publish Ingress Controllers with internal cloud load balancers. For +example: + +[source,yaml] +---- +apiVersion: operator.openshift.io/v1 +kind: IngressController +metadata: + namespace: openshift-ingress-operator + name: internal +spec: + endpointPublishingStrategy: + type: LoadBalancerService + loadBalancer: + scope: Internal +---- + +See the +link:https://kubernetes.io/docs/concepts/services-networking/#internal-load-balancer.[Kubernetes +Services documentation] for implementation details. + +Once set, `.spec.endpointPublishingStrategy.loadBalancer.scope` cannot +be changed. To change the scope, delete and recreate the Ingress Controller. + +The `default` Ingress Controller can be made internal by deleting and recreating +it. + +See xref:../networking/ingress-operator.adoc#configuring-ingress[Ingress +Operator in {product-title}] for more information. + +[id="ocp-4-2-kubernetes-cni-plug-in-additions"] +==== Kubernetes CNI plug-in additions and enhancements + +Several Kubernetes CNI plug-ins are added or enhanced in {product-title} +{product-version} to grow capability. + +These SR-IOV solutions remain in Technology Preview in {product-title} +{product-version}: + +* RDMA and RoCE Support +* DPDK Mode for SR-IOV VFs +* Admission Controller +* Operator + +New CNI plug-ins: + +* IPVLAN +* Bridge with VLAN +* Static IPAM + +[id="ocp-4-2-enablement-of-GPUs"] +==== Enablement of GPUs in an OpenShift cluster + +GPUs are now supported on Red Hat Enterprise Linux (RHEL) 7 nodes. They are not +supported on RHEL CoreOS nodes because of lack of support for CUDA driver and +driver containers. + +[id="ocp-4-2-web-console"] +=== Web console + +[id="ocp-4-2-custom-branding"] +==== Console customization options + +You can customize the {product-title} web console to set a custom logo, links, +notification banners, and command line downloads. This is especially helpful if you +need to tailor the web console to meet specific corporate or government +requirements. + +See Customizing the web console for more information. + +[id="ocp-4-2-new-api-explorer"] +==== New API Explorer + +You can now easily search and manage API resources in the *Explore API +Resources* dashboard located at *Home* -> *Explore*. + +View the schema for each API and what parameters being supported, manage the +instances of the API, and review the access of each API. + +[id="ocp-4-2-machine-autoscaler"] +==== Machine Autoscaler + +You can now scale your cluster with the Machine Autoscaler. The Machine +Autoscaler adjusts the number of Machines in the MachineSets being deployed in +your cluster. Increase Machines when the cluster runs out of resources to +support more deployments. Any changes, such as the minimum or maximum number of +instances, are immediately applied to the MachineSet that MachineAutoscalers +target. + +[id="ocp-4-2-developer-perspective"] +==== Developer Perspective + +The Developer perspective adds a developer-focused perspective to the web +console. It provides workflows specific to developer use cases, such as creation +and deployment of applications to {product-title} using multiple options. It +provides a visual representation of the applications within a project, their +build status, and the components and services associated with them, enabling +easy interaction and monitoring. It incorporates Serverless capabilities +(Technology Preview) and the ability to create workspaces to edit your +application code using Eclipse Che. + +[id="ocp-4-2-prometheus-queries"] +==== Prometheus queries + +You can now run Prometheus queries directly in the web console. Navigate to +*Monitoring* -> *Metrics*. + +[id="ocp-4-2-web-console-idps"] +==== Identity providers + +On the cluster OAuth configuration page, more identity providers (IDPs) are +provided for the user to log in to the cluster. The IDPs include GitHub, GitLab, +Google, LDAP, Keystone, and so on. + +[id="ocp-4-2-general-web-console-updates"] +==== General web console updates + +* The dashboard is redesigned with more metrics. +* *Catalog* is moved to the *Developer* perspective: *Developer* -> *Add+* -> *From +Catalog*. +* Status of projects is now moved to the *Workloads* tab on the project details page. +* OperatorHub is now located under the *Operators* menu. +* There is now support for chargeback. You can break down the reserved and used +resources requested by applications. +* There is now support for native templates without needing to enable the Service +Catalog, which is now deprecated. + +[id="ocp-4-2-notable-technical-changes"] +== Notable technical changes + +{product-title} {product-version} introduces the following notable technical +changes. + +[discrete] +[id="ocp-4-2-corsAllowedOrigins"] +==== corsAllowedOrigins + +`corsAllowedOrigins` can now be configured. See +xref:../authentication/allowing-javascript-access-api-server.adoc[Allowing +JavaScript-based access to the API server from additional hosts] for more +information. + +[discrete] +[id="ocp-4-2-new-cni-plugins"] +==== New CNI plug-ins + +There are two new CNI plug-ins for Multus: bridge and ipvlan. + +[discrete] +[id="ocp-4-2-cno-supports-SimpleMacvlan"] +==== CNO supports SimpleMacvlan + +CNO now supports configuring SimpleMacvlan. + +[discrete] +[id="ocp-4-2-layers"] +==== Builds maintain their layers + +In {product-title} {product-version}, builds keep their layers by default. + +[discrete] +[id="ocp-4-2-windows-builds-not-supported"] +==== Builds on Windows + +Builds are not scheduled on Windows nodes. + +[discrete] +[id="ocp-4-2-ingress-controller-support-disabled"] +==== Ingress controller support disabled + +Ingress controller TLS 1.0 and 1.1 support is now disabled to match the +Mozilla intermediate security profile. + +New and upgraded ingress controllers will no longer support these TLS versions. + +[discrete] +[id="ocp-4-2-remove-csc-usage"] +==== Reduce OperatorHub complexity by removing CatalogSourceConfig usage + +OperatorHub has been updated to reduce the +number of API resources a cluster administrator must interact with and +streamline the installation of new Operators on {product-title} 4.2. + +To work with OperatorHub in {product-title} 4.1, cluster administrators +primarily interacted with OperatorSource and CatalogSourceConfig API resources. +OperatorSources are used to add external datastores where Operator bundles are +stored. + +CatalogSourceConfigs were used to enable an Operator present in the +OperatorSource of your cluster. Behind the scenes, it configured an Operator +Lifecycle Manager (OLM) CatalogSource so that the Operator could then be managed +by OLM. + +To reduce complexity, OperatorHub in {product-title} 4.2 no longer uses +CatalogSourceConfigs in the workflow of installing Operators. Instead, +CatalogSources are still created as a result of adding OperatorSources to the +cluster, however Subscription resources are now created directly using the +CatalogSource. + +[discrete] +[id="ocp-4-2-global-catalog-namespace"] +==== Global catalog namespace change + +In {product-title} 4.1, the default global catalog namespace, where +CatalogSources are installed by default, is +`openshift-operator-lifecycle-manager`. Starting with {product-title} 4.2, this +has changed to the `openshift-marketplace` namespace. + +If you have installed an Operator from OperatorHub on a {product-title} 4.1 +cluster, the CatalogSource is in the same namespace as the Subscription. These +Subscriptions are not affected by this change and should continue to behave +normally after a cluster upgrade. + +In {product-title} 4.2, if you install an Operator from OperatorHub, the +Subscription created refers to a CatalogSource located in the new global +catalog namespace `openshift-marketplace`. + +[discrete] +[id="ocp-4-2-global-catalog-namespace-workaround"] +===== Workaround for existing Subscriptions in the previous global catalog namespace + +If you have existing CatalogSources in the old +`openshift-operator-lifecycle-manager` namespace, any existing Subscription +objects that are referring to the CatalogSource will fail to upgrade, and new +Subscription objects that are referring to the CatalogSource will fail to +install. + +To workaround such upgrade failures: + +.Procedure +. Move the CatalogSource object from the previous global catalog namespace to +the `openshift-marketplace` namespace. + +[id="ocp-41-deprecated-features"] +=== Deprecated features + +[discrete] +[id="ocp-4-2-deprecation-of-service-catalog"] +==== Deprecation of the Service Catalog, the Template Service Broker, the Ansible Service Broker, and their Operators + +In {product-title} {product-version}, the Service Catalog, the Template Service +Broker, the Ansible Service Broker, and their Operators are deprecated. They +will be removed in a future {product-title} release. + +The following related APIs will be removed in a future release: + +* `*.servicecatalog.k8s.io/v1beta1` +* `*.automationbroker.io/v1alpha1` +* `*.osb.openshift.io/v1` + +[discrete] +[id="ocp-4-2-deprecation-of-operatorsources"] +==== Deprecation of OperatorSources + +In a future release, OperatorSources will be deprecated from OperatorHub and the +`operatorsource.operators.coreos.com/v1` API will be removed. + +[discrete] +[id="ocp-4-2-deprecation-of-oapi-endpoint"] +==== Deprecation of `/oapi` endpoint from `oc` + +The usage of the `/oapi` endpoint from `oc` is being deprecated and will be +removed in a future release. The `/oapi` endpoint was responsible for serving +non-group {product-title} APIs and was removed in 4.1. + +[discrete] +[id="ocp-4-2-deprecation-of-short-flag"] +==== Deprecation of the `-short` flag of `oc version` + +The `oc version --short` flag is now deprecated. The `--short` flag printed +default output. + +[discrete] +[id="ocp-4-2-oc-adm-migrate-commands-deprecated"] +==== `oc adm migrate` commands + +The `oc adm migrate` command and all of its subcommands except for `oc adm +migrate template-instances` are now deprecated. + +[discrete] +[id="ocp-4-2-PV-snapshots-deprecated"] +==== Persistent volume snapshots + +In the {product-title} 4.1 Release Notes, persistent volume snapshot was +incorrectly marked as Technology Preview. This functionality was deprecated in +{product-title} 3.11. + +[discrete] +[id="ocp-4-2-EFS"] +==== EFS + +In the {product-title} 4.1 Release Notes, EFS was incorrectly marked as +generally available. This is being included as a Technology Preview feature in +{product-title} {product-version}. + +[discrete] +[id="ocp-4-2-recycle-reclaim-policy"] +==== Recycle reclaim policy + +Recycle reclaim policy is now deprecated. Dynamic provisioning is recommended. + +[id="ocp-4-2-bug-fixes"] +== Bug fixes + +List goes here. + +[id="ocp-4-2-technology-preview"] +== Technology Preview features + +Some features in this release are currently in Technology Preview. These +experimental features are not intended for production use. Note the +following scope of support on the Red Hat Customer Portal for these features: + +link:https://access.redhat.com/support/offerings/techpreview[Technology Preview +Features Support Scope] + +In the table below, features marked *TP* indicate _Technology Preview_ and +features marked *GA* indicate _General Availability_. Features marked as *-* +indicate that the feature is removed from the release or deprecated. + +.Technology Preview Tracker +[cols="4",options="header"] +|==== +|Feature |OCP 3.11 |OCP 4.1 |OCP 4.2 + +|Prometheus Cluster Monitoring +|GA +|GA +|GA + +|Local Storage Persistent Volumes +|TP +|TP +|TP + +|CRI-O for runtime pods +|GA* footnoteref:[disclaimer, Features marked with `*` indicate delivery in a z-stream patch.] +|GA +|GA + +|Tenant Driven Snapshotting +|TP +|TP +|TP + +|`oc` CLI Plug-ins +|TP +|TP +|TP + +|Service Catalog +|GA +|GA +|-- + +|Template Service Broker +|GA +|GA +|-- + +|OpenShift Ansible Service Broker +|GA +|GA +|-- + +|Network Policy +|GA +|GA +|GA + +|Multus +|- +|GA +|GA + +|New Add Project Flow +|GA +|GA +|GA + +|Search Catalog +|GA +|GA +|GA + +|Cron Jobs +|GA +|GA +|GA + +|Kubernetes Deployments +|GA +|GA +|GA + +|StatefulSets +|GA +|GA +|GA + +|Explicit Quota +|GA +|GA +|GA + +|Mount Options +|GA +|GA +|GA + +|System Containers for Docker, CRI-O +|- +|- +|- + +|Hawkular Agent +|- +|- +|- + +|Pod PreSets +|- +|- +|- + +|experimental-qos-reserved +|TP +|TP +|TP + +|Pod sysctls +|GA +|GA +|GA. See xref:ocp-4-2-known-issues[Known issues] for current limitations. + +|Central Audit +|GA +|- +|- + +|Static IPs for External Project Traffic +|GA +|GA +|GA + +|Template Completion Detection +|GA +|GA +|GA + +|`replicaSet` +|GA +|GA +|GA + +|Fluentd Mux +|TP +|TP +|TP + +|Clustered MongoDB Template +|- +|- +|- + +|Clustered MySQL Template +|- +|- +|- + +|ImageStreams with Kubernetes Resources +|GA +|GA +|GA + +|Device Manager +|GA +|GA +|GA + +|Persistent Volume Resize +|GA +|GA +|GA + +|Huge Pages +|GA +|GA +|GA + +|CPU Pinning +|GA +|GA +|GA + +|Admission Webhooks +|TP +|GA +|GA + +|External provisoner for AWS EFS +|TP +|TP +|TP + +|Pod Unidler +|TP +|TP +|TP + +|Node Problem Detector +|TP +|TP +|TP + +|Ephemeral Storage Limit/Requests +|TP +|TP +|TP + +|Descheduler +|TP +|TP +|TP + +|CephFS +|TP +|TP +|TP + +|Podman +|TP +|TP +|TP + +|Kuryr CNI Plug-in +|TP +|TP +|TP + +|Sharing Control of the PID Namespace +|TP +|TP +|TP + +|Manila Provisioner +|TP +|TP +|TP + +|Cluster Administrator console +|GA +|GA +|GA + +|Cluster Autoscaling (AWS Only) +|GA +|GA +|GA + +|Container Storage Interface (CSI) +|TP +|TP +|GA + +|Operator Lifecycle Manager +|TP +|GA +|GA + +|Red Hat OpenShift Service Mesh +|TP +|TP +|TP + +|"Fully Automatic" Egress IPs +|GA +|GA +|GA + +|Pod Priority and Preemption +|GA +|GA +|GA + +|Multi-stage builds in Dockerfiles +|TP +|GA +|GA + +|OVN +| +|TP +|TP + +|OVN SDN +| +|TP +|TP + +|HPA custom metrics adapter based on Prometheus +| +|TP +|TP + +|Machine health checks +| +|TP +|TP + +|Raw Block with iSCSI +| +| +|TP + +|OperatorHub +| +| +|GA +|==== + +[id="ocp-4-2-known-issues"] +== Known issues + +* Unsafe sysctl cannot be used in {product-title} {product-version}. +(link:https://bugzilla.redhat.com/show_bug.cgi?id=1690754[*BZ#1690754*]) + +* `git clone` operations that go through an HTTPS proxy will fail. Non-TLS (HTTP) +proxies can be used successfully. +(link:https://bugzilla.redhat.com/show_bug.cgi?id=1750650[*BZ#1750650*]) + +* Builds that use image references that correlate to an image mirror, which is +the case in a disconnected environment, will fail to pull or push those image +references if the mirror requires authentication. +(link:https://bugzilla.redhat.com/show_bug.cgi?id=1745192[*BZ#1745192*]) + +* Image stream import does not use mirrors. This is often used in disconnected environments. +(link:https://bugzilla.redhat.com/show_bug.cgi?id=1741391[*BZ#1741391*]) + +* `git clone` via SSH does not work through a proxy. + +* If builds use a build secret, it is strongly recommended that layers are squashed +using `imageOptimizationPolicy: SkipLayers`. Otherwise, secrets might leak in +`source` and `docker` strategy builds. diff --git a/release_notes/versioning-policy.adoc b/release_notes/versioning-policy.adoc index 04bc7332573f..b46320e5cbb9 100644 --- a/release_notes/versioning-policy.adoc +++ b/release_notes/versioning-policy.adoc @@ -1,4 +1,4 @@ -[id="ocp-4-1-versioning-policy"] +[id="ocp-4-2-versioning-policy"] = {product-title} Versioning Policy include::modules/common-attributes.adoc[] :context: release-notes @@ -10,7 +10,7 @@ supported APIs, excluding alpha APIs (which may be changed without notice) and beta APIs (which may occasionally be changed in a non-backwards compatible manner). -Red Hat did not publicly release {product-title} 4.0 and, instead, is releasing +Red Hat did not publicly release {product-title} 4.0 and, instead, released {product-title} {product-version} directly after version 3.11. The {product-title} version must match between master and node hosts, excluding diff --git a/welcome/index.adoc b/welcome/index.adoc index de09d74cbe77..e7e488036ffd 100644 --- a/welcome/index.adoc +++ b/welcome/index.adoc @@ -14,7 +14,7 @@ To navigate the {product-title} {product-version} documentation, you can either * Select the activity that interests you from the contents of this Welcome page ifdef::openshift-enterprise,openshift-origin[] -You can start with an **xref:../architecture/architecture.adoc#architecture-overview-architecture[Introduction to {product-title}]** and the xref:../release_notes/ocp-4-1-release-notes.adoc#ocp-4-1-release-notes[{product-title} {product-version} Release Notes]. +You can start with an **xref:../architecture/architecture.adoc#architecture-overview-architecture[Introduction to {product-title}]** and the xref:../release_notes/ocp-4-2-release-notes.adoc#ocp-4-2-release-notes[{product-title} {product-version} Release Notes]. endif::[] ifdef::openshift-dedicated,openshift-online,openshift-aro[]