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
-[ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io]
37
38
-[ ] Supporting documentation e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes
38
39
39
-
40
40
## Summary
41
41
42
-
This document describes how deb & rpm packages get published as part of cutting a release, with the tooling the release and patch management teams have at hand ([anago], [gcbmgr] and others from [k/release], [k/k/build] and potentially other places).
42
+
This document describes how deb and rpm packages get published in the same way as the currently [documented package mirror] as part of cutting a release, with the tooling the release management team has at hand ([krel] and others from [k/release], [k/k/build] and potentially other places).
- Package spec file updates are not committed to a public repository.
54
54
- The packages get published on Google infrastructure.
55
-
- After publishing a new release but before sending out the release
56
-
notification emails the process needs to be paused. Googlers need to build
57
-
and publish the deb and rpm packages before the branch management team can
58
-
continue and send notification can be sent out.
55
+
- After publishing a new release but before sending out the release notification
56
+
emails the process needs to be paused. Googlers need to build and publish the
57
+
deb and rpm packages before the branch manager can continue and send the
58
+
release announcement.
59
59
- We can only publish packages for stable releases right now.
60
60
- We use different packages in CI then we officially release.
61
61
62
62
This all prolongs the release process, it is a hard dependency on a small group of people from one company (and its infrastructure), and we only ever publish and test packages very late in the release process.
63
63
64
64
### Goals
65
65
66
-
The whole process should be folded into the release tooling, it should be part of the release process, and should not involve anyone other than the release branch / patch release team.
66
+
The whole process should be folded into the release tooling, it should be part of the release process, and should not involve anyone other than the release managers.
67
67
For each release the release team cuts, packages should also be generated and published automatically.
68
68
69
69
There should be multiple channels users can subscribe to: **stable**, **dev**, and **nightly**.
70
70
71
-
72
71
### Non-Goals
73
72
74
-
The actual package generation is a different problem that is discussed in [this KEP][pkg-gen-kep].
73
+
The original version of this KEP had the following statement:
74
+
75
+
> The actual package generation is a different problem that is discussed in [this KEP][pkg-gen-kep].
76
+
77
+
Based on a review of this KEP, Kubernetes contributor @saschagrunert wants SIG
78
+
Release to own the process of automatically building and publishing the packages
An [End User] is used in the CNCF sense to refer to consumers of the Kubernetes artifacts built and published by [Release Managers]
113
+
114
+
[end user]: https://www.cncf.io/enduser/
98
115
99
116
```
100
-
Scenario: Enduser installs a kubelet from the stable channel
101
-
Given a user has configured the officially documented package mirror for stable releases for a specific kubernetes minor version ("the minor") on their machine
102
-
When they use the system's package manager to query the list of kubelet packages available (e.g. apt-cache policy kubelet)
103
-
Then they see a list of all stable patch versions of the kubelet that stem from the minor and a preference to install the latest patch version of the kubelet
104
-
But don't see any alpha, beta, rc or nightly releases of the kubelet from this specific kubernetes minor version
105
-
And they don't see any packages of any other kubernetes minor release
117
+
Scenario: End User lists the available packages from the stable channel
118
+
Given an End User has configured the officially documented package mirror for stable releases on their machine
119
+
When they use their system's package manager to query the list of kubelet packages available (e.g. apt-cache policy kubelet)
120
+
Then they see a list of all stable patch versions of the kubelet and a preference to install the latest available patch version
121
+
But they do not see any alpha, beta, release candidate or nightly releases of the kubelet package from this specific kubernetes minor version
122
+
And they do not see any packages of any other kubernetes minor releases
106
123
```
107
124
108
125
```
109
126
Scenario: Release tools automatically publish new packages
110
-
Given a release team member ran `./gcbmgr stage master --build-at-head --nomock`
111
-
And a release team member ran `./gcbmgr release master --buildversion=${{VERSIONID}} --nomock`
112
-
When a user inspects the officially documented deb and rpm kubernetes repositories for this specific kubernetes minor version
113
-
Then they see the newly cut alpha releases published in the alpha channel only
127
+
Given a Release Manager ran `./krel stage --nomock` and `./krel release --nomock` to create a new release (alpha, beta, rc or final).
128
+
When an End User inspects the officially documented deb and rpm kubernetes repositories for this specific kubernetes minor version
129
+
Then they see the newly cut releases published in the appropriate channel only
114
130
```
115
131
116
132
```
117
-
Scenario: End users can get the public key the packages or the repository metadata is signed with
118
-
Given a user has a system configured with not allowing unsigned untrusted package repositories
119
-
And they have setup the officially documented repository for a specific kubernetes minor release
120
-
When they download the public key from the location stated in the official documentation
121
-
And they configure their system's package manager to use that key
122
-
And they use their system's package manager to install a package from this specific kubernetes minor release
123
-
Then their package manager will not complain about untrusted packages, sources or repositories
133
+
Scenario: End users can retrieve the public key that signed the packages, or the repository metadata is signed with
134
+
Given an End User configured their system to disallow the use of unsigned, untrusted package repositories
135
+
And they have setup the officially documented repository for a specific kubernetes minor release
136
+
When they download the public key from the location stated in the official documentation
137
+
And they configure their system's package manager to use that key
138
+
And they use their system's package manager to install a package from this specific kubernetes minor release
139
+
Then their package manager does not complain about untrusted packages, sources or repositories
124
140
```
125
141
126
142
<!--
@@ -135,46 +151,47 @@ Scenario: [...]
135
151
136
152
### Implementation Details/Notes/Constraints
137
153
138
-
Packages will be published for different ...
139
-
-**`${dist}`**: a combination of `<distribution>-<code-name-or-version>`
-`nightly`: any package cut automatically on a daily basis (optionally)
150
165
151
-
This means, that end-users can configure their systems’ package managers to use those different `${channel}`s of a kubernetes `${k8s_release}` for their `${dist}`.
166
+
This means, that End Users can configure their systems’ package managers to use
167
+
those different `${channel}`s of a kubernetes `${k8s_release}` for their
168
+
corresponding package manager.
152
169
153
170
A configuration for the package managers might look something like:
154
171
155
172
- deb:
156
-
```
157
-
# deb http://apt.kubernetes.io/${dist} ${k8s_release} ${channel}
158
-
deb http://apt.kubernetes.io/debian-jessie 1.13 nightly
159
-
```
173
+
```
174
+
# deb http://apt.kubernetes.io ${k8s_release} ${channel}
175
+
deb [signed-by=/etc/keyrings/kubernetes-keyring.gpg] http://apt.kubernetes.io/debian 1.26 nightly
Different architectures will be published into the same repos, it is up to the package managers to pull and install the correct package for the target platform.
173
190
191
+
Ideally and optionally, publishing/promoting a package means to commit a change
192
+
to a configuration file which triggers a "package promotion tool", which:
174
193
175
-
Ideally, publishing/promoting a package means to commit a change to a configuration file which triggers a "package promotion tool".
176
-
That tool ...
177
-
- manages which packages need to go into which `${channel}` for which `${dist}` of which `${k8s_release}`
194
+
- manages which packages need to go into which `${channel}` for which package manager of which `${k8s_release}`
178
195
- guard that by the packages checksum
179
196
- is able to promote a package from a bucket and also from a `${channel}` to the other
180
197
- work off of a declarative configuration
@@ -183,12 +200,13 @@ This tool does for packages what the [Image Promoter][img-promoter] tool does
183
200
for container images. Therefore, ideally, we can implement this work-flow as part
184
201
of the [Image Promoter][img-promoter] or at least use its libraries.
185
202
186
-
187
-
As soon as the [redirector] is in place the repositories should be mirrored and the [redirector] should be used.
We can achieve the same directly in `krel release`, means that the dedicated
206
+
promotion is an optional part of this KEP. As an intermediate solution we can
207
+
also leave the package publishing on the Google side and focus on building them
208
+
before graduating the KEP to GA.
209
+
192
210
All architectures that are supported by the [package building tool][pkg-gen-kep] should be published.
193
211
This KEP suggests to start with publishing a single supported architecture
194
212
(e.g. `linux/amd64`) and extend that iteratively, when we verify that creating
@@ -199,59 +217,72 @@ process (see also: [Risks](#risks-and-mitigations)).
199
217
200
218
### Risks and Mitigations
201
219
202
-
- *Risk*: We don't find a proper way to share secrets like the signing key
203
-
*Mitigation*: TBA
204
-
- *Risk*: Building all the packages for all the distributions and their version takes too long to be done nightly or via cutting the release
205
-
*Mitigation*: TBA
220
+
-_Risk_: We don't find a proper way to share secrets like the signing key
221
+
_Mitigation_: Using a third party tool like 1Password
222
+
-_Risk_: Building all the packages for all the distributions and their version takes too long to be done nightly or via cutting the release
223
+
_Mitigation_: We do not deliver nightly packages.
206
224
207
225
## Design Details
208
226
209
227
### Test Plan
210
228
211
-
There should be a post-publish tests, which can be run as part or after the release process
212
-
- pull packages from the official mirrors (via the [redirector] if in place)
229
+
There should be post-publish tests, which can be run as part or after the release process
230
+
231
+
- pull packages from the official mirrors
213
232
- assert that all the packages we expect to be published are actually published
233
+
- assert that all published packages have the expected checksums
214
234
- assert that the packages and the repo metadata is signed with the current signing key
235
+
- assert that installed packages contain the correct binary versions
215
236
216
237
### Graduation Criteria
217
238
218
-
In general we can keep the current way of publishing (via googlers onto google's infrastructure) and introduce new infrastructure in parallel.
239
+
In general we can keep the current way of publishing (via googlers onto Google's
240
+
infrastructure) and introduce new infrastructure in parallel. For example, it is
241
+
still possible to optimize the current package building process by splitting up
242
+
the rapture script into a build script and sign/publish one. This would allow us
243
+
to intermediately automate the build step to publish artifacts on the release
244
+
GCS bucket. The sign/publish script would then be able to utilize those
245
+
artifacts and publish them into the current destination manually.
219
246
220
247
Once the tests show that the mirrors are good, we can adapt the official documentation. This includes:
248
+
221
249
- for release team members:
222
250
- How and where do the packages get published as part of the release process
223
-
- How can the post-publish test be run
251
+
- How can the post-publish tests be run
224
252
- for kubernetes contributors:
225
-
- How and where do the nightlies get published
253
+
- How and where do the nightly builds get published
226
254
- for kubernetes users:
227
-
- Which repository are available for users
228
-
- How to configure their package managers
229
-
230
255
256
+
- Which repositories are available for users
257
+
- How to configure their package managers
231
258
259
+
- There is a documented process to create and publish deb and rpm packages of Kubernetes components
260
+
- It is possible to consume the published deb and rpm packages using steps that document the process
232
261
233
262
#### Alpha
234
263
235
-
- Needed infrastructure is in place (buckets, dns, repos, …)
264
+
- Needed infrastructure is in place (buckets, DNS, repos, …)
265
+
- There is a documented process to create and publish deb and rpm packages of Kubernetes components
266
+
- It is possible to consume the published deb and rpm packages using steps similar to the documented process
236
267
237
268
#### Alpha -> Beta Graduation
238
269
270
+
-[ ][krel] creates deb and rpm packages of Kubernetes components
271
+
-[ ] Packages are signed
272
+
-[ ] Repository indices are updated after packages are copied to the repositories
273
+
-[ ] Post-publish tests are written and run as part of the release process
274
+
-[ ] Nightly builds will be built and published on a daily basis using [krel] which will be improved to take over this task from [kubepkg] making use of [pre-existing periodic jobs] (https://github.com/kubernetes/test-infra/blob/97cb34fa9e2bfc4af35de3e561cb9fc5a1094da1/config/jobs/kubernetes/sig-release/kubernetes-builds.yaml#L120-L166)
275
+
-[ ] Documentation written checked to be complete and correct.
276
+
-[ ] Outline deprecation policy and communication plan
239
277
240
-
- [anago] [creates packages][pkg-gen-kep] and published those packages as part of the release process
241
-
- post-publish tests are in places and run as part of the release process
242
-
- nightlies will be build and published on a daily basis
0 commit comments