mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-07 00:48:01 +01:00
Mod channel doc
This commit is contained in:
Jack Ottofaro
@@ -7,89 +7,85 @@
|
||||
// * updating/updating-disconnected-cluster.adoc
|
||||
|
||||
[id="understanding-upgrade-channels_{context}"]
|
||||
= Understanding {product-title} upgrade channels
|
||||
= {product-title} Upgrade Channels and Releases
|
||||
|
||||
In {product-title} 4.1, Red Hat introduced the concept of upgrade channels for
|
||||
recommending the appropriate upgrade versions to your cluster. Upgrade channels
|
||||
separate upgrade strategies and also are used to control the cadence of updates.
|
||||
Channels are tied to a minor version of {product-title}. For instance,
|
||||
{product-title} {product-version} channels will never include an upgrade to a
|
||||
4.5 release. This ensures administrators make an explicit decision to upgrade to
|
||||
the next minor version of {product-title}. Channels only control updates and
|
||||
have no impact on the version of the cluster you install; the
|
||||
`openshift-install` binary for a given patch level of {product-title} always
|
||||
installs that patch level.
|
||||
In {product-title} 4.1, Red Hat introduced the concept of channels for
|
||||
recommending the appropriate release versions for cluster upgrade. By controlling
|
||||
the pace of upgrades, these upgrade channels allow users to choose an upgrade
|
||||
strategy. Upgrade channels are tied to a minor version of
|
||||
{product-title}. For instance, {product-title} {product-version}
|
||||
upgrade channels will never include an upgrade to a 4.5 release. This ensures
|
||||
administrators make an explicit decision to upgrade to the next minor version of
|
||||
{product-title}. Upgrade channels only control release selection and have
|
||||
no impact on the version of the cluster you install; the `openshift-install`
|
||||
binary for a given patch level of {product-title} always installs that patch level.
|
||||
|
||||
{product-title} {product-version}, which includes the upgrade from the previous 4.3
|
||||
release, has three upgrade channels to choose from:
|
||||
{product-title} {product-version} has the following upgrade channels to choose from:
|
||||
|
||||
* candidate-{product-version}
|
||||
* fast-{product-version}
|
||||
* stable-{product-version}
|
||||
|
||||
The upgrade channels contain two types of updates:
|
||||
[discrete]
|
||||
== candidate-{product-version} Channel
|
||||
|
||||
. General Availability Software (or GA) - These versions of {product-title} are
|
||||
fully supported and are considered production quality. You may upgrade to the general
|
||||
availability release from either of the fast and stable channels.
|
||||
The candidate-{product-version} channel will contain candidate builds for a z-stream
|
||||
({product-version}.z) release.
|
||||
Release candidates contain all the features of the product but they are not supported and
|
||||
should only be used to test feature acceptance and assist in qualifying the next version
|
||||
of {product-title}.
|
||||
A release candidate is any build (e.g. 4.3.0-rc.3, 4.3.0) that is available in the candidate
|
||||
channel.
|
||||
After a version lands in the candidate channel, it goes through more quality checks and if
|
||||
it meets the quality standard it is promoted to fast-{product-version} or stable-{product-version}
|
||||
channels.
|
||||
So if a given release is available in the candidate-{product-version} channel and also in the fast-{product-version}
|
||||
or stable-{product-version} channels, it is a Red Hat supported version.
|
||||
Additionally candidate-{product-version} may include dead end releases from which there are no or ever
|
||||
be recommended upgrades.
|
||||
|
||||
The candidate-{product-version} channel also allows upgrading from a previous minor version of
|
||||
{product-title} to {product-version}.
|
||||
|
||||
. Release Candidate Software (or RC) - These versions of {product-title} are
|
||||
representative of the eventual general availability release and are available only
|
||||
in the candidate-{product-version} channel. The release candidate will contain all
|
||||
the features of the product. You are allowed to upgrade from a release candidate to
|
||||
another release candidate and to upgrade from a previous minor version of
|
||||
{product-title} to the current release candidate. Release candidate builds are not
|
||||
supported by Red Hat and you will not be able to upgrade from a release candidate to
|
||||
the general availability release of {product-title}. Candidates should be used to
|
||||
test feature acceptance and assist in qualifying the next version of
|
||||
{product-title} in your infrastructure.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
Release candidates differ from the nightly builds found on try.openshift.com. You
|
||||
cannot upgrade nightly builds to nightly builds. Nightly builds are available for
|
||||
early access to features but are not upgradable or supported.
|
||||
Release candidates differ from the nightly builds found on try.openshift.com. Nightly
|
||||
builds are available for early access to features but updating to or from nightly
|
||||
builds is neither recommended nor supported. Nightly builds are not avilable in
|
||||
any upgrade channel.
|
||||
====
|
||||
|
||||
For GA versions, the fast and stable channels present a choice between receiving
|
||||
updates as soon as they are available or allowing Red Hat to control the rollout of
|
||||
those updates.
|
||||
[discrete]
|
||||
== fast-{product-version} Channel
|
||||
|
||||
The fast-{product-version} channel is updated with new {product-version} patch
|
||||
versions as soon as Red Hat declares the given patch as a general availability
|
||||
release. As such, these releases are fully supported, are production quality and have
|
||||
performed well while available as a release candidate in the candidate-{product-version}
|
||||
channel from where they were promoted. Some time after a release appears in
|
||||
fast-{product-version} it will also appear in stable-{product-version}. Releases will
|
||||
never appear in stable-{product-version} before they appear in fast-{product-version}.
|
||||
|
||||
The fast-{product-version} channel also allows upgrading from a previous minor version of
|
||||
{product-title}.
|
||||
|
||||
[discrete]
|
||||
== fast-{product-version}
|
||||
== stable-{product-version} Channel
|
||||
|
||||
The fast channel is updated with new {product-version} patch versions as soon as Red
|
||||
Hat declares they are generally available. Use this channel if you wish to receive
|
||||
updates as soon as they are available or for your pre-production environments when
|
||||
participating in the connected customer program. This channel will contain all
|
||||
z-stream ({product-version}.z) updates but will not suggest upgrades to the next
|
||||
minor release (4.5.z) when the next minor release is available.
|
||||
Like the fast-{product-version} channel, the stable-{product-version} channel will
|
||||
only contain releases that have been declared general availability are therefore
|
||||
fully supported. However the stable-{product-version} channel will gradually roll out
|
||||
releases to customers based on data from our SRE teams, support services, and
|
||||
pre-production and production environments that participate in our connected customer
|
||||
program, rather than being immediately available as they are in the fast-{product-version}
|
||||
channel. For patch and CVE fixes this delay can range from several hours to a day
|
||||
and allows an extra period of assessment in how the software performs.
|
||||
|
||||
The stable-{product-version} channel also allows upgrading from a previous minor version of
|
||||
{product-title}.
|
||||
|
||||
[discrete]
|
||||
== stable-{product-version}
|
||||
|
||||
The stable channel will contain updates on a time delay as they are gradually
|
||||
rolled out to customers based on data from our SRE teams, support services, and
|
||||
pre-production and production environments that participate in our connected
|
||||
customer program, rather than being immediately available as they are in the fast
|
||||
channel. For patch and CVE fixes this can range from several hours to a day and
|
||||
allows an extra period of assessment in how the software performs. If issues are
|
||||
detected during rollout, upgrades to that version may be blocked in both the fast
|
||||
and stable channels, and a new version may be introduced that will be the new
|
||||
preferred upgrade target.
|
||||
|
||||
Customers can improve this process by configuring pre-production systems on the
|
||||
fast channel, production systems on the stable channel, and participating in Red
|
||||
Hat’s connected customer program - this allows Red Hat to observe the impact of
|
||||
updates on your specific hardware and software configurations. Future releases may
|
||||
improve or alter the pace at which updates move from the fast to the stable channels.
|
||||
|
||||
If issues are discovered with an upgrade between patch levels, Red Hat may withdraw
|
||||
that suggested upgrade for affected versions. A newer patch would become available
|
||||
in the appropriate channels and be suggested for upgrade.
|
||||
|
||||
[discrete]
|
||||
== Upgrade version paths
|
||||
== Upgrade Version Paths
|
||||
|
||||
{product-title} maintains an upgrade recommendation service that understands the
|
||||
version of {product-title} you have installed as well as the path to take within
|
||||
@@ -101,19 +97,48 @@ following in the fast-{product-version} channel:
|
||||
* {product-version}.3
|
||||
* {product-version}.4
|
||||
|
||||
The service only recommends upgrades that have been tested and have no known issues.
|
||||
The service only recommends upgrades that have been tested and have no serious issues.
|
||||
If you are on {product-version}.1 and {product-title} is allowing you to select
|
||||
{product-version}.4, then it is safe for you to go from .{product-version}.1 to .{product-version}.4. Likewise,
|
||||
the absence of {product-version}.2 may be due to a CVE that was fixed in {product-version}.3 and Red Hat no
|
||||
longer suggests upgrading to a known vulnerable version. If an issue is found that
|
||||
results in a new version being retracted from the recommendations, Red Hat will
|
||||
release a new version that is capable of upgrading from all necessary versions,
|
||||
including the retracted version.
|
||||
longer suggests upgrading to a known vulnerable version.
|
||||
|
||||
Update stability depends on your channel. The presence of an update recommendation in
|
||||
the candidate-{product-version} channel does not imply that the update is supported.
|
||||
It means that no serious issues have been found with the update yet, but there may
|
||||
not be significant traffic through the update to suggest stability. The presence of
|
||||
an update recommendation in the fast-{product-version} or stable-{product-version}
|
||||
channels is a declaration that the update is fully supported while it is in the
|
||||
channel. While releases will never be removed from a channel, update recommendations
|
||||
which exhibit serious issues will be removed from all channels. Updates initiated
|
||||
after the update recommendation has been removed may not be supported.
|
||||
|
||||
Red Hat will eventually provide supported update paths from any supported (fast-{product-version}
|
||||
or stable-{product-version}) release to the latest release in {product-version}.z,
|
||||
although there may be delays while safe paths away from troubled releases are
|
||||
constructed and verified.
|
||||
|
||||
[discrete]
|
||||
== Disconnected clusters
|
||||
== Fast and Stable Channel Usage and Strategies
|
||||
|
||||
Customers which have chosen to not be connected to Red Hat and are curating their
|
||||
The fast-{product-version} and stable-{product-version} channels present a choice between receiving
|
||||
general availability releases as soon as they are available or allowing Red Hat to
|
||||
control the rollout of those updates. If issues are detected during rollout or at a
|
||||
later time, upgrades to that version may be blocked in both the fast-{product-version} and
|
||||
stable-{product-version} channels, and a new version may be introduced that will be the new
|
||||
preferred upgrade target.
|
||||
|
||||
Customers can improve this process by configuring pre-production systems on the
|
||||
fast-{product-version} channel, production systems on the stable-{product-version} channel,
|
||||
and participating in Red Hat’s xref:../support/remote_health_monitoring/about-remote-health-monitoring.adoc[connected customer program]. This program allows Red
|
||||
Hat to observe the impact of updates on your specific hardware and software
|
||||
configurations. Future releases may improve or alter the pace at which updates move
|
||||
from the fast-{product-version} to the stable-{product-version} channel.
|
||||
|
||||
[discrete]
|
||||
== Restricted Network Clusters
|
||||
|
||||
Customers who have chosen to not be connected to Red Hat and are controlling their
|
||||
own {product-title} container image content manually should consult the Red Hat
|
||||
errata associated with product releases and note any comments impacting upgrades.
|
||||
During upgrade the user interface may caution about switching between these versions
|
||||
@@ -121,10 +146,20 @@ and it is up to the customer to ensure they have correctly selected the appropri
|
||||
version before bypassing those cautions.
|
||||
|
||||
[discrete]
|
||||
== Switching between channels
|
||||
== Switching Between Channels
|
||||
|
||||
It is supported for customers to switch between the fast and stable channel at any
|
||||
time. Channels only offer suggested upgrades, and will never suggest a dangerous
|
||||
upgrade. If you switch to the candidate channel after installing from a GA version,
|
||||
you will see a warning the current version is not recognized, and you can safely
|
||||
switch back to a GA channel.
|
||||
It is supported for customers to switch from the stable-{product-version} channel to
|
||||
the fast-{product-version} at any time. Customers can also switch to the
|
||||
candidate-{product-version} at any time but should be aware that some releases in the
|
||||
candidate-{product-version} channel may be release candidates and therefore not
|
||||
supported. A customer can switch from candidate-{product-version} to fast-{product-version}
|
||||
if their current release is a general availability release. Customers can always
|
||||
switch from fast-{product-version} to stable-{product-version}, although there may
|
||||
be a delay of up to a day if their current release was recently promoted to
|
||||
fast-{product-stable} while they wait for the release to be promoted to
|
||||
stable-{product-version}. If you change to a channel that does not include your
|
||||
current release, an alert will fire, no updates will be recommended, and you can
|
||||
safely change back to your original channel at any point.
|
||||
|
||||
Please refer to the <<candidate-{product-version} Channel>> section above to understand the
|
||||
distinction between a release candidate and a general avilability release.
|
||||
|
||||
Reference in New Issue
Block a user