You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In {product-title} 4.1, Red Hat introduced the concept of upgrade channels for
13
-
recommending the appropriate upgrade versions to your cluster. Upgrade channels
14
-
separate upgrade strategies and also are used to control the cadence of updates.
15
-
Channels are tied to a minor version of {product-title}. For instance,
16
-
{product-title} {product-version} channels will never include an upgrade to a
17
-
4.5 release. This ensures administrators make an explicit decision to upgrade to
18
-
the next minor version of {product-title}. Channels only control updates and
19
-
have no impact on the version of the cluster you install; the
20
-
`openshift-install` binary for a given patch level of {product-title} always
21
-
installs that patch level.
22
-
23
-
{product-title} {product-version}, which includes the upgrade from the previous 4.3
24
-
release, has three upgrade channels to choose from:
10
+
= {product-title} Upgrade Channels and Releases
11
+
12
+
In {product-title} 4.1, Red Hat introduced the concept of channels for
13
+
recommending the appropriate release versions for cluster upgrade. By controlling
14
+
the pace of upgrades, these upgrade channels allow users to choose an upgrade
15
+
strategy. Upgrade channels are tied to a minor version of
16
+
{product-title}. For instance, {product-title} {product-version}
17
+
upgrade channels will never include an upgrade to a 4.5 release. This ensures
18
+
administrators make an explicit decision to upgrade to the next minor version of
19
+
{product-title}. Upgrade channels only control release selection and have
20
+
no impact on the version of the cluster you install; the `openshift-install`
21
+
binary for a given patch level of {product-title} always installs that patch level.
22
+
23
+
{product-title} {product-version} has the following upgrade channels to choose from:
25
24
26
25
* candidate-{product-version}
27
26
* fast-{product-version}
28
27
* stable-{product-version}
29
28
30
-
The upgrade channels contain two types of updates:
31
-
32
-
. General Availability Software (or GA) - These versions of {product-title} are
33
-
fully supported and are considered production quality. You may upgrade to the general
34
-
availability release from either of the fast and stable channels.
35
-
36
-
. Release Candidate Software (or RC) - These versions of {product-title} are
37
-
representative of the eventual general availability release and are available only
38
-
in the candidate-{product-version} channel. The release candidate will contain all
39
-
the features of the product. You are allowed to upgrade from a release candidate to
40
-
another release candidate and to upgrade from a previous minor version of
41
-
{product-title} to the current release candidate. Release candidate builds are not
42
-
supported by Red Hat and you will not be able to upgrade from a release candidate to
43
-
the general availability release of {product-title}. Candidates should be used to
44
-
test feature acceptance and assist in qualifying the next version of
45
-
{product-title} in your infrastructure.
46
-
+
29
+
[discrete]
30
+
== candidate-{product-version} Channel
31
+
32
+
The candidate-{product-version} channel will contain candidate builds for a z-stream
33
+
({product-version}.z) release.
34
+
Release candidates contain all the features of the product but they are not supported and
35
+
should only be used to test feature acceptance and assist in qualifying the next version
36
+
of {product-title}.
37
+
A release candidate is any build (e.g. 4.3.0-rc.3, 4.3.0) that is available in the candidate
38
+
channel.
39
+
After a version lands in the candidate channel, it goes through more quality checks and if
40
+
it meets the quality standard it is promoted to fast-{product-version} or stable-{product-version}
41
+
channels.
42
+
So if a given release is available in the candidate-{product-version} channel and also in the fast-{product-version}
43
+
or stable-{product-version} channels, it is a Red Hat supported version.
44
+
Additionally candidate-{product-version} may include dead end releases from which there are no or ever
45
+
be recommended upgrades.
46
+
47
+
The candidate-{product-version} channel also allows upgrading from a previous minor version of
48
+
{product-title} to {product-version}.
49
+
47
50
[NOTE]
48
51
====
49
-
Release candidates differ from the nightly builds found on try.openshift.com. You
50
-
cannot upgrade nightly builds to nightly builds. Nightly builds are available for
51
-
early access to features but are not upgradable or supported.
52
+
Release candidates differ from the nightly builds found on try.openshift.com. Nightly
53
+
builds are available for early access to features but updating to or from nightly
54
+
builds is neither recommended nor supported. Nightly builds are not avilable in
55
+
any upgrade channel.
52
56
====
53
57
54
-
For GA versions, the fast and stable channels present a choice between receiving
55
-
updates as soon as they are available or allowing Red Hat to control the rollout of
56
-
those updates.
57
-
58
58
[discrete]
59
-
== fast-{product-version}
59
+
== fast-{product-version} Channel
60
+
61
+
The fast-{product-version} channel is updated with new {product-version} patch
62
+
versions as soon as Red Hat declares the given patch as a general availability
63
+
release. As such, these releases are fully supported, are production quality and have
64
+
performed well while available as a release candidate in the candidate-{product-version}
65
+
channel from where they were promoted. Some time after a release appears in
66
+
fast-{product-version} it will also appear in stable-{product-version}. Releases will
67
+
never appear in stable-{product-version} before they appear in fast-{product-version}.
60
68
61
-
The fast channel is updated with new {product-version} patch versions as soon as Red
62
-
Hat declares they are generally available. Use this channel if you wish to receive
63
-
updates as soon as they are available or for your pre-production environments when
64
-
participating in the connected customer program. This channel will contain all
65
-
z-stream ({product-version}.z) updates but will not suggest upgrades to the next
66
-
minor release (4.5.z) when the next minor release is available.
69
+
The fast-{product-version} channel also allows upgrading from a previous minor version of
70
+
{product-title}.
67
71
68
72
[discrete]
69
-
== stable-{product-version}
70
-
71
-
The stable channel will contain updates on a time delay as they are gradually
72
-
rolled out to customers based on data from our SRE teams, support services, and
73
-
pre-production and production environments that participate in our connected
74
-
customer program, rather than being immediately available as they are in the fast
75
-
channel. For patch and CVE fixes this can range from several hours to a day and
76
-
allows an extra period of assessment in how the software performs. If issues are
77
-
detected during rollout, upgrades to that version may be blocked in both the fast
78
-
and stable channels, and a new version may be introduced that will be the new
79
-
preferred upgrade target.
73
+
== stable-{product-version} Channel
80
74
81
-
Customers can improve this process by configuring pre-production systems on the
82
-
fast channel, production systems on the stable channel, and participating in Red
83
-
Hat’s connected customer program - this allows Red Hat to observe the impact of
84
-
updates on your specific hardware and software configurations. Future releases may
85
-
improve or alter the pace at which updates move from the fast to the stable channels.
75
+
Like the fast-{product-version} channel, the stable-{product-version} channel will
76
+
only contain releases that have been declared general availability are therefore
77
+
fully supported. However the stable-{product-version} channel will gradually roll out
78
+
releases to customers based on data from our SRE teams, support services, and
79
+
pre-production and production environments that participate in our connected customer
80
+
program, rather than being immediately available as they are in the fast-{product-version}
81
+
channel. For patch and CVE fixes this delay can range from several hours to a day
82
+
and allows an extra period of assessment in how the software performs.
86
83
87
-
If issues are discovered with an upgrade between patch levels, Red Hat may withdraw
88
-
that suggested upgrade for affected versions. A newer patch would become available
89
-
in the appropriate channels and be suggested for upgrade.
84
+
The stable-{product-version} channel also allows upgrading from a previous minor version of
85
+
{product-title}.
90
86
91
87
[discrete]
92
-
== Upgrade version paths
88
+
== Upgrade Version Paths
93
89
94
90
{product-title} maintains an upgrade recommendation service that understands the
95
91
version of {product-title} you have installed as well as the path to take within
@@ -101,30 +97,69 @@ following in the fast-{product-version} channel:
101
97
* {product-version}.3
102
98
* {product-version}.4
103
99
104
-
The service only recommends upgrades that have been tested and have no known issues.
100
+
The service only recommends upgrades that have been tested and have no serious issues.
105
101
If you are on {product-version}.1 and {product-title} is allowing you to select
106
102
{product-version}.4, then it is safe for you to go from .{product-version}.1 to .{product-version}.4. Likewise,
107
103
the absence of {product-version}.2 may be due to a CVE that was fixed in {product-version}.3 and Red Hat no
108
-
longer suggests upgrading to a known vulnerable version. If an issue is found that
109
-
results in a new version being retracted from the recommendations, Red Hat will
110
-
release a new version that is capable of upgrading from all necessary versions,
111
-
including the retracted version.
104
+
longer suggests upgrading to a known vulnerable version.
105
+
106
+
Update stability depends on your channel. The presence of an update recommendation in
107
+
the candidate-{product-version} channel does not imply that the update is supported.
108
+
It means that no serious issues have been found with the update yet, but there may
109
+
not be significant traffic through the update to suggest stability. The presence of
110
+
an update recommendation in the fast-{product-version} or stable-{product-version}
111
+
channels is a declaration that the update is fully supported while it is in the
112
+
channel. While releases will never be removed from a channel, update recommendations
113
+
which exhibit serious issues will be removed from all channels. Updates initiated
114
+
after the update recommendation has been removed may not be supported.
115
+
116
+
Red Hat will eventually provide supported update paths from any supported (fast-{product-version}
117
+
or stable-{product-version}) release to the latest release in {product-version}.z,
118
+
although there may be delays while safe paths away from troubled releases are
119
+
constructed and verified.
112
120
113
121
[discrete]
114
-
== Disconnected clusters
122
+
== Fast and Stable Channel Usage and Strategies
115
123
116
-
Customers which have chosen to not be connected to Red Hat and are curating their
124
+
The fast-{product-version} and stable-{product-version} channels present a choice between receiving
125
+
general availability releases as soon as they are available or allowing Red Hat to
126
+
control the rollout of those updates. If issues are detected during rollout or at a
127
+
later time, upgrades to that version may be blocked in both the fast-{product-version} and
128
+
stable-{product-version} channels, and a new version may be introduced that will be the new
129
+
preferred upgrade target.
130
+
131
+
Customers can improve this process by configuring pre-production systems on the
132
+
fast-{product-version} channel, production systems on the stable-{product-version} channel,
133
+
and participating in Red Hat’s xref:../support/remote_health_monitoring/about-remote-health-monitoring.adoc[connected customer program]. This program allows Red
134
+
Hat to observe the impact of updates on your specific hardware and software
135
+
configurations. Future releases may improve or alter the pace at which updates move
136
+
from the fast-{product-version} to the stable-{product-version} channel.
137
+
138
+
[discrete]
139
+
== Restricted Network Clusters
140
+
141
+
Customers who have chosen to not be connected to Red Hat and are controlling their
117
142
own {product-title} container image content manually should consult the Red Hat
118
143
errata associated with product releases and note any comments impacting upgrades.
119
144
During upgrade the user interface may caution about switching between these versions
120
145
and it is up to the customer to ensure they have correctly selected the appropriate
121
146
version before bypassing those cautions.
122
147
123
148
[discrete]
124
-
== Switching between channels
125
-
126
-
It is supported for customers to switch between the fast and stable channel at any
127
-
time. Channels only offer suggested upgrades, and will never suggest a dangerous
128
-
upgrade. If you switch to the candidate channel after installing from a GA version,
129
-
you will see a warning the current version is not recognized, and you can safely
130
-
switch back to a GA channel.
149
+
== Switching Between Channels
150
+
151
+
It is supported for customers to switch from the stable-{product-version} channel to
152
+
the fast-{product-version} at any time. Customers can also switch to the
153
+
candidate-{product-version} at any time but should be aware that some releases in the
154
+
candidate-{product-version} channel may be release candidates and therefore not
155
+
supported. A customer can switch from candidate-{product-version} to fast-{product-version}
156
+
if their current release is a general availability release. Customers can always
157
+
switch from fast-{product-version} to stable-{product-version}, although there may
158
+
be a delay of up to a day if their current release was recently promoted to
159
+
fast-{product-stable} while they wait for the release to be promoted to
160
+
stable-{product-version}. If you change to a channel that does not include your
161
+
current release, an alert will fire, no updates will be recommended, and you can
162
+
safely change back to your original channel at any point.
163
+
164
+
Please refer to the <<candidate-{product-version} Channel>> section above to understand the
165
+
distinction between a release candidate and a general avilability release.
0 commit comments