forked from siderolabs/talos
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathrelease.toml
147 lines (113 loc) · 5.05 KB
/
release.toml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
# commit to be tagged for new release
commit = "HEAD"
project_name = "Talos"
github_repo = "siderolabs/talos"
match_deps = "^github.com/((talos-systems|siderolabs)/[a-zA-Z0-9-]+)$"
# previous release
# TODO: frezbo: remove once we have 1.2.0 release
previous = "v1.2.0-beta.0"
pre_release = true
preface = """\
"""
[notes]
[notes.updates]
title = "Component Updates"
description="""\
* containerd: 1.6.8
* runc: v1.1.4
* Linux: 5.15.64
* Kubernetes: v1.25.0
"""
[notes.track-cli-action-progress]
title = "Tracking progress of shutdown, reboot, reset and upgrade from CLI"
description = """\
`talosctl` subcommands `shutdown`, `reboot`, `reset` and `upgrade` now have a new flag `--wait` to
wait until the operation is completed, displaying information on the current status of each node.
A new `--debug` flag is added to these commands to get the kernel logs output from these nodes if the operation fails.

"""
[notes.talos-config-kernel-param-variable-substitution]
title = "Variable substitution for URL query parameter in the talos.config kernel parameter"
description="""\
The kernel parameter talos.config can now substitute system information into placeholders inside its URL query values. This example shows all supported variables:
```http://example.com/metadata?h=${hostname}&m=${mac}&s=${serial}&u=${uuid}```
"""
[notes.strategic-merge]
title = "Strategic merge machine configuration patching"
description="""\
In addition to JSON (RFC6902) patches Talos now supports [strategic merge patching](https://www.talos.dev/v1.2/talos-guides/configuration/patching/).
For example, machine hostname can be set with the following patch:
```yaml
machine:
network:
hostname: worker1
```
Patch format is detected automatically.
"""
[notes.gen-secrets-from-pki]
title = "Generating Talos secrets from PKI directory"
description="""\
It is now possible to generate a secrets bundle from a Kubernetes PKI directory (e.g. `/etc/kubernetes/pki`).
You can also specify a bootstrap token to be used in the secrets bundle.
This secrets bundle can then be used to generate a machine config.
This facilitates migrating clusters (e.g. created using `kubeadm`) to Talos.
```
talosctl gen secrets --kubernetes-bootstrap-token znzio1.1ifu15frz7jd59pv --from-kubernetes-pki /etc/kubernetes/pki
talosctl gen config --with-secrets secrets.yaml my-cluster https://172.20.0.1:6443
```
"""
[notes.packet-capture]
title = "Packet Capture"
description="""\
Talos now supports capturing packets on a network interface with `talosctl pcap` command:
talosctl pcap --interface eth0
"""
[notes.stable-hostname]
title = "Stable Default Hostname"
description="""\
Talos now generates the default hostname (when there is no explicitly specified hostname) for the nodes based on the
node id (e.g. `talos-2gd-76y`) instead of using the DHCP assigned IP address (e.g. `talos-172-20-0-2`).
This ensures that the node hostname is not changed when DHCP assigns a new IP to a node.
Please note: the stable hostname generation algorithm changed between v1.2.0-beta.0 and v1.2.0-beta.1, please take care when upgrading
from versions >= 1.2.0-alpha.1 to versions >= 1.2.0-beta.1 when using stable default hostname feature.
"""
[notes.kubespan-kubernetes-nets]
title = "KubeSpan Kubernetes Network Advertisement"
description="""\
KubeSpan no longer by default advertises Kubernetes pod networks of the node over KubeSpan.
This means that CNI should handle encapsulation of pod-to-pod traffic into the node-to-node tunnel,
and node-to-node traffic will be handled by KubeSpan.
This provides better compatibility with popular CNIs like Calico and Cilium.
Old behavior can be restored by setting `.machine.kubespan.advertiseKubernetesNetworks = true` in the machine config.
"""
[notes.kubernetes-discovery]
title = "Kubernetes Discovery Backend"
description="""\
Kubernetes cluster discovery backend is now disabled by default for new clusters.
This backend doesn't provide any benefits over the Discovery Service based backend, while it
causes issues for KubeSpan enabled clusters when control plane endpoint is KubeSpan-routed.
For air-gapped installations when the Discovery Service is not enabled, Kubernetes Discovery Backend can be enabled by applying
the following machine configuration patch:
```yaml
cluster:
discovery:
registries:
kubernetes:
disabled: false
```
"""
[notes.apply-config]
title = "Apply Config Patches"
description="""\
`talosctl apply-config` now supports patching the machine config file in memory before submitting it to the node.
"""
[make_deps]
[make_deps.tools]
variable = "TOOLS"
repository = "github.com/siderolabs/tools"
[make_deps.pkgs]
variable = "PKGS"
repository = "github.com/siderolabs/pkgs"
[make_deps.extras]
variable = "EXTRAS"
repository = "github.com/siderolabs/extras"