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
Copy file name to clipboardExpand all lines: doc/design/channel-naming.md
+16-38Lines changed: 16 additions & 38 deletions
Original file line number
Diff line number
Diff line change
@@ -2,16 +2,6 @@
2
2
3
3
This guide shows OLM users how to use and choose naming conventions for channels to manage their operator upgrades.
4
4
5
-
## GOALS
6
-
7
-
8
-
Some goals of this document include:
9
-
10
-
- Define what a channel is and how it is defined
11
-
- Explain different naming conventions for channels and how it impacts operator upgrades
12
-
- Describe how operators can be promoted from one channel to another
13
-
- Describe future designs for OLM that alter the way channels are used
14
-
15
5
## CHANNELS
16
6
17
7
Operator Lifecycle Manager (OLM) provides a channel concept that allows you
@@ -26,6 +16,7 @@ For each version of an operator you can specify a channel that it will belong
26
16
to. Since there can be multiple versions of an operator within a channel,
27
17
there is a notion of the latest version within a channel, or the channel head
28
18
version. It's the channel head that OLM will install for most subscriptions.
19
+
29
20
There can also be multiple channels for a given operator package which is
30
21
used to offer different support models (e.g. pre-release, production). Here
31
22
is a diagram that shows the relationship of operator versions to channels:
@@ -68,8 +59,8 @@ then be subscribed to. If you mis-type the channel name, there is nothing
68
59
that validates the channel value because the channel is known by whatever
69
60
you provide.
70
61
71
-
Note that you can specify a default channel for a given operator package.
72
-
This default channel is used when an operator is being installed to fulfill
62
+
Note that you can specify a default channel for a given operator package. This
63
+
default channel is used when an operator is being installed to fulfill
73
64
a dependency requirement of another operator. The dependent operator will
74
65
be installed from the dependent operator’s default channel as the first
75
66
choice, falling back to other channels the dependent operator provides as
@@ -103,28 +94,15 @@ spec:
103
94
sourceNamespace: my-operators
104
95
```
105
96
106
-
The Subscription is providing hints to OLM which are used to determine
107
-
exactly which version of an operator will get deployed onto the cluster, in
108
-
this example OLM will look for an operator to deploy that belongs to the
109
-
preview channel within a specified catalog index source.
97
+
The Subscription is providing hints to OLM which are used to determine exactly which version of an operator will get deployed onto the cluster, in this example OLM will look for an operator to deploy that belongs to the preview channel within a specified catalog index source.
110
98
111
-
Note that exactly which operator version is deployed can depend on more than
112
-
what you specify in the Subscription. On initial install, OLM will always
113
-
attempt to install whatever is the head of the specified channel by default.
114
-
Settings within the operator’s CSV also are used by OLM to determine exactly
115
-
which operator version OLM will deploy or upgrade.
99
+
Note that exactly which operator version is deployed can depend on more than what you specify in the Subscription. On initial install, OLM will always attempt to install whatever is the head of the specified channel by default. Settings within the operator’s CSV also are used by OLM to determine exactly which operator version OLM will deploy or upgrade.
116
100
117
101
## NAMING
118
102
119
-
Channel names are used to imply what form of upgrade you want to offer for
120
-
your operator. For example, you might have an operator that has a preview or
121
-
alpha version which is not supported as well as a version where support is
122
-
offered.
103
+
Channel names are used to imply what form of upgrade you want to offer for your operator. For example, you might have an operator that has a preview or alpha version which is not supported as well as a version where support is offered.
123
104
124
-
The names you choose are notional and up to you to decide, however, picking
125
-
good channel names requires some basic guidance. What is described below
126
-
are different channel naming conventions that are commonly used by the
127
-
operator community to denote different operator upgrade use cases.
105
+
The names you choose are notional and up to you to decide, however, picking good channel names requires some basic guidance. What is described below are different channel naming conventions that are commonly used by the operator community to denote different operator upgrade use cases.
128
106
129
107
### Naming Convention Rules
130
108
@@ -140,9 +118,9 @@ operator community to denote different operator upgrade use cases.
140
118
#### Example 1
141
119
142
120
| Channel Name | Purpose |
143
-
| :------------- | -----------:|
144
-
|preview | Pre-release operators that would typically not have support offered and might be considered experimental. |
145
-
|fast | Released, supported operators which are still being monitored to assess stability/quality prior to promoting them as stable. Generally used by early adopters or for testing in pre-production environments. |
121
+
| :------------- |:----------- |
122
+
| preview | Pre-release operators that would typically not have support offered and might be considered experimental. |
123
+
| fast | Released, supported operators which are still being monitored to assess stability/quality prior to promoting them as stable. Generally used by early adopters or for testing in pre-production environments. |
146
124
| stable | Released, supported operators that have been observed to be stable through usage by consumers of the fast channel.\||
147
125
148
126
With the above channel naming convention, you are always moving end users to
@@ -162,9 +140,9 @@ the 1.3 versions. In that case, you would end up with channels as
162
140
recommended above but with major/minor version information applied as follows:
163
141
164
142
| Channels for 1.3 | Channels for 2.4 |
165
-
| :------------- | -----------:|
166
-
|preview-1.3 | preview-2.4 |
167
-
|fast-1.3 | fast-2.4 |
143
+
| :------------- |:----------- |
144
+
| preview-1.3 | preview-2.4 |
145
+
| fast-1.3 | fast-2.4 |
168
146
| stable-1.3 | stable-2.4 \||
169
147
170
148
#### Example 3
@@ -176,9 +154,9 @@ Version 13. In this case, you might have the need to advertise your
176
154
channels by the operand version as follows:
177
155
178
156
| Channels for Postgres 12 | Channels for Postgres 13 |
179
-
| :------------- | -----------:|
180
-
|preview-pg-12 | preview-pg-13 |
181
-
|fast-pg-12 | fast-pg-13 |
157
+
| :------------- |:----------- |
158
+
| preview-pg-12 | preview-pg-13 |
159
+
| fast-pg-12 | fast-pg-13 |
182
160
| stable-pg-12 | stable-pg-13 \||
183
161
184
162
In this example, subscribers know which database version they are subscribing
0 commit comments