diff --git a/release_notes/ocp_3_10_release_notes.adoc b/release_notes/ocp_3_10_release_notes.adoc index 1408c73e7790..d339fbc1bb97 100644 --- a/release_notes/ocp_3_10_release_notes.adoc +++ b/release_notes/ocp_3_10_release_notes.adoc @@ -87,11 +87,104 @@ This release adds improvements related to the following components and concepts. [[ocp-310-notable-technical-changes]] == Notable Technical Changes -{product-title} 3.9 introduces the following notable technical changes. +{product-title} 3.10 introduces the following notable technical changes. [discrete] -[[ocp-310-change1]] -=== Change 1 +[[ocp-310-major-changes-to-cluster-architecture]] +=== Major Changes to Cluster Architecture + +{product-title} 3.10 introduces major architecture changes in how control +plane and node components are deployed, affecting new installations and upgrades +from {product-title} 3.9. + +_(New architecture changes diagram, WIP)_ + +The following sections highlight the most significant changes, with more detail +provided in the Architecture Guide. + +[discrete] +[[ocp-310-control-plane-changes]] +==== Control Plane as Static Pods + +While previously run as systemd services, the control plane components +(apiserver, controllers, and etcd when co-located with a master) are now run as +static pods by the kubelet on master hosts. + +This is now the only supported way they can be run; system containers are no +longer supported, with the exception of the node service RHEL Atomic Host. The +upgrade will change over to the new architecture automatically. Control plane +components continue to read configurations from the *_/etc/origin/master/_* and +*_/etc/etcd/_* directories. + +You can see the pods after the control plane starts using `oc get pods -n kube-system`, +and `exec`, `log`, and `inspect` them using normal `oc` CLI commands. + +[discrete] +===== Why? + +Static pods are managed directly by the kubelet daemon on a specific node, +without the API server having to observe it. With this simplified architecture, +master and node static pods do not have an associated replication controller, +and the kubelet daemon itself watches and restarts them if they crash. Static +pods are always bound to one kubelet daemon and always run on the same node with +it. + +[discrete] +[[ocp-310-nodes-bootstrapped]] +==== Nodes Bootstrapped from the Master + +Nodes are now bootstrapped from the master by default, which means nodes will +pull their pre-defined configuration and client and server certificates from the +master. The 3.10 upgrade will automatically transform your nodes to use this new +mode. + +The node components *openshift-sdn* and *openvswitch* are now run using a +DaemonSet instead of a systemd service. + +[discrete] +===== Why? + +The goal for bootstrapping is to allow faster node start-up by reducing the +differences between nodes, as well as centralizing more configuration and +letting the cluster converge on the desired state. This enables certificate +rotation and centralized certificate management by default (use `oc get csr` to see +pending certificates). + +[discrete] +[[ocp-310-containerized-installation-removed]] +==== Containerized Installation Method Removed + +The containerized installation method for OpenShift Container Platform (where +components run as standard container images) has been removed and is no longer +supported starting in 3.10. The 3.10 upgrade migrates RHEL Server hosts to the +RPM-based method and RHEL Atomic Hosts to the system container-based method (for +the node service only), which are the only supported methods for the respective +RHEL variants. + +[discrete] +===== Why? + +This reduces the number of installation and upgrade paths, and aligns better +with features to be introduced in future releases. + +[discrete] +[[ocp-310-configuration-files]] +==== Configuration Files + +To upgrade from {product-title} 3.9 to 3.10, you must first create +a configuration file that maps your previous master and node configurations to +the new ConfigMap usage, and supply the mapping when initiating your cluster +upgrade. This ensures that the upgrade does not begin without this critical +information, and that you are not left at the end of the upgrade with hosts +using the previous style deployment. + +In addition, the *_/etc/sysconfig/(origin|atomic-openshift)-(api|controllers)_* +files will no longer be used. A new *_/etc/origin/master/master.env_* file can +be used to set environment variables for the static pods. The set of +configuration available as environment variables is limited (proxy and log +levels). Future versions of {product-title} will remove this configuration in +favor of control plane files, so consider the *_master.env_* file a last resort +and deprecated. [[ocp-310-bug-fixes]] == Bug Fixes @@ -308,39 +401,11 @@ features marked *GA* indicate _General Availability_. [[ocp-310-known-issues]] == Known Issues -* {product-title} 3.10 adds the ability for multiple instances of an APB to be -invoked in the same namespace. This new ability requires relying on a globally -unique identifier (GUID) for each instance. While instances deployed by an 3.9 -version of an APB lack the GUID, 3.10 APBs require it. -+ --- -A 3.10 APB is unable to manage a 3.9 deployed service because it lacks the -newly required GUID. This causes clusters upgraded from 3.9 to 3.10 to result in -an error if an application that was previously deployed on 3.9 is then -deprovisioned from 3.10 APB. - -There are two workarounds to this issue currently: - -* After the cluster upgrade to 3.10 has completed, delete the namespace of the -application and recreate it. This will use the 3.10 version of the APB and -function as expected. - -* Modify the configuration of the OpenShift Ansible broker to remain on the 3.9 -version of APBs. This is not recommended, however, as it has the downside of the -broker using 3.10 code while the APBs use the older 3.9 version: - -.. Follow the procedure in -xref:../install_config/oab_broker_configuration.adoc#install-config-oab-modifying[Modifying the OpenShift Ansible Broker Configuration] to change the label to `v3.9`. -.. Run the `apb bootstrap` command to bootstrap the broker and relist the catalog. - -(link:https://bugzilla.redhat.com/show_bug.cgi?id=1586108[*BZ#1586108*]) --- - [[ocp-310-asynchronous-errata-updates]] == Asynchronous Errata Updates -Security, bug fix, and enhancement updates for {product-title} 3.9 are released -as asynchronous errata through the Red Hat Network. All {product-title} 3.9 +Security, bug fix, and enhancement updates for {product-title} 3.10 are released +as asynchronous errata through the Red Hat Network. All {product-title} 3.10 errata is https://access.redhat.com/downloads/content/290/[available on the Red Hat Customer Portal]. See the https://access.redhat.com/support/policy/updates/openshift[{product-title} @@ -360,8 +425,8 @@ emails to generate. This section will continue to be updated over time to provide notes on enhancements and bug fixes for future asynchronous errata releases of -{product-title} 3.9. Versioned asynchronous releases, for example with the form -{product-title} 3.9.z, will be detailed in subsections. In addition, releases in +{product-title} 3.10. Versioned asynchronous releases, for example with the form +{product-title} 3.10.z, will be detailed in subsections. In addition, releases in which the errata text cannot fit in the space provided by the advisory will be detailed in subsections that follow.