Skip to content

Commit 969bfed

Browse files
dprodanov4dprodanov4
authored
Merge branch 'release-3.3' into release-3.3.3
2 parents 6035cb7 + 597745f commit 969bfed

File tree

5 files changed

+157
-3
lines changed

5 files changed

+157
-3
lines changed

‎.github/workflows/test-deploy.yml‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9,6 +9,7 @@ on:
99
pull_request:
1010
branches:
1111
- main
12+
- "release-3.*"
1213
# Review gh actions docs if you want to further define triggers, paths, etc
1314
# https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#on
1415

‎asciidoc/day2/migration.adoc‎

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -26,6 +26,23 @@ Always perform cluster migrations from the `latest Z-stream` release of `Edge {p
2626
Always migrate to the `Edge {static-edge-version}` release. For subsequent post-migration upgrades, refer to the <<day2-mgmt-cluster, management>> and <<day2-downstream-clusters, downstream>> cluster sections.
2727
====
2828

29+
The following table lists the different types of clusters and the methods to upgrade clusters:
30+
31+
[[Clusters-and-methods-to-upgrade-downstream-clusters]]
32+
.Clusters and methods to upgrade downstream clusters
33+
|===
34+
| Cluster type | Method
35+
36+
|EIB provisioned clusters
37+
|See <<day2-migration-mgmt-fleet>> for details.
38+
39+
|Metal^3^ provisioned clusters
40+
|See <<atip-lifecycle-downstream, Downstream cluster upgrades>> for details.
41+
42+
|Phone-home provisioned clusters
43+
|See https://ranchermanager.docs.rancher.com/{rancher-docs-version}/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes#upgrading-the-kubernetes-version[Upgrading the Kubernetes Version] for Kubernetes version upgrade and <<day2-downstream-clusters, Downstream clusters>> for SUC, Operating system, and other components.
44+
|===
45+
2946
[#day2-migration-mgmt]
3047
== Management Cluster
3148
:cluster-type: management

‎asciidoc/edge-book/edge.adoc‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -135,7 +135,7 @@ Tips and tricks for Edge components
135135
136136
include::../tips/eib.adoc[leveloffset=+1]
137137
include::../tips/elemental.adoc[leveloffset=+1]
138-
138+
include::../tips/metal3.adoc[leveloffset=+1]
139139
140140
//--------------------------------------------
141141
// Third-Party Integration

‎asciidoc/edge-book/versions.adoc‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -94,6 +94,10 @@
9494
:version-sriov-network-operator-chart: 303.0.2+up1.5.0
9595
:version-sriov-upstream: 1.5.0
9696

97+
// capi-provider-metal3
98+
// edu, Oct 9, 2025 :: Used to link the CRDs on the docs site like
99+
// https://doc.crds.dev/github.com/metal3-io/cluster-api-provider-metal3/infrastructure.cluster.x-k8s.io/Metal3MachineTemplate/[email protected]#spec-template-spec-hostSelector-matchLabels
100+
:version-capi-provider-metal3: [email protected]
97101

98102
// ============================================================================
99103
// Manual Version Entries

‎asciidoc/tips/metal3.adoc‎

Lines changed: 134 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,24 @@
1+
[#tips-metal3]
12
= *Metal^3^*
3+
:revdate: 2025-10-07
4+
:page-revdate: {revdate}
5+
:experimental:
6+
7+
ifdef::env-github[]
8+
:imagesdir: ../images/
9+
:tip-caption: :bulb:
10+
:note-caption: :information_source:
11+
:important-caption: :heavy_exclamation_mark:
12+
:caution-caption: :fire:
13+
:warning-caption: :warning:
14+
endif::[]
15+
16+
:imagesdir: ../images/
17+
18+
== Ironic
19+
20+
=== Predictable network names
221

3-
.Ironic:
422
Due to a link:../components/metal3.adoci#L31[known issue], if you are trying to configure predictable names for the target OS network devices and you end up in errors, seeing that the discovered device names have different naming pattern, then you have a couple of options:
523

624
_Option 1:_ Use two network configuration secrets, one for the inspection/provisioning phase and another for the deployed OS.
@@ -100,5 +118,119 @@ How to get the UUIDs you need:
100118
now in the output files you should have the UUIDs that you can use in your configuration.
101119

102120
3. Alternatively, if you don't use OpenSUSE or SLES, you can use the nmc through the Edge Image Builder container image:
103-
`podman run -it --rm -v $(pwd):/path/to/your/config:Z --entrypoint=/usr/bin/nmc registry.suse.com/edge/3.3/edge-image-builder:1.2.1 generate --confi
121+
`podman run -it --rm -v $(pwd):/path/to/your/config:Z --entrypoint=/usr/bin/nmc registry.suse.com/edge/{version-edge-registry}/edge-image-builder:{version-eib} generate --confi
104122
g-dir /path/to/your/config --output-dir /where/you/want/it`
123+
124+
== `BareMetalHost` selection and Cluster association
125+
126+
Once a Metalˆ3ˆ cluster object and its corresponding associated objects are created, a process to choose which `BareMetalHost` will be part of
127+
the cluster is performed.
128+
This process connects a `BareMetalHost` with a specific `Metal3MachineTemplate` using standard
129+
https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/[Kubernetes labels] and selectors.
130+
131+
As an example, each `BareMetalHost` is labeled to identify its properties and intended cluster
132+
(e.g., its cluster-role, the cluster name, location, etc.):
133+
134+
----
135+
apiVersion: metal3.io/v1alpha1
136+
kind: BareMetalHost
137+
metadata:
138+
name: mynode1
139+
labels:
140+
cluster-role: control-plane
141+
cluster: foobar
142+
location: madrid
143+
datacenter: xyz
144+
<snip>
145+
---
146+
apiVersion: metal3.io/v1alpha1
147+
kind: BareMetalHost
148+
metadata:
149+
name: mynode2
150+
labels:
151+
cluster-role: worker
152+
cluster: foobar
153+
location: madrid
154+
datacenter: xyz
155+
<snip>
156+
---
157+
apiVersion: metal3.io/v1alpha1
158+
kind: BareMetalHost
159+
metadata:
160+
name: mynode3
161+
labels:
162+
cluster-role: worker
163+
cluster: foobar2
164+
location: madrid
165+
datacenter: xyz
166+
<snip>
167+
...
168+
----
169+
170+
Then, the `Metal3MachineTemplate` object uses the https://doc.crds.dev/github.com/metal3-io/cluster-api-provider-metal3/infrastructure.cluster.x-k8s.io/Metal3MachineTemplate/{version-capi-provider-metal3}#spec-template-spec-hostSelector[`spec.hostSelector`] field to match the desired `BareMetalHost`.
171+
172+
Both https://doc.crds.dev/github.com/metal3-io/cluster-api-provider-metal3/infrastructure.cluster.x-k8s.io/Metal3MachineTemplate/{version-capi-provider-metal3}#spec-template-spec-hostSelector-matchLabels[`matchLabels`] (for exact key-value matching) and https://doc.crds.dev/github.com/metal3-io/cluster-api-provider-metal3/infrastructure.cluster.x-k8s.io/Metal3MachineTemplate/{version-capi-provider-metal3}#spec-template-spec-hostSelector-matchExpressions[`matchExpressions`] (for more complex rules) can be used:
173+
174+
----
175+
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
176+
kind: Metal3MachineTemplate
177+
metadata:
178+
name: foobar-cluster-controlplane
179+
namespace: mynamespace
180+
spec:
181+
template:
182+
spec:
183+
hostSelector:
184+
matchLabels:
185+
cluster-role: control-plane
186+
cluster: foobar
187+
<snip>
188+
---
189+
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
190+
kind: Metal3MachineTemplate
191+
metadata:
192+
name: foobar-cluster-worker
193+
namespace: mynamespace
194+
spec:
195+
template:
196+
spec:
197+
hostSelector:
198+
matchExpressions:
199+
- { key: cluster-role, operator: In, values: [worker] }
200+
- { key: cluster, operator: In, values: [foobar] }
201+
<snip>
202+
----
203+
204+
[NOTE]
205+
====
206+
Kubernetes namespaces can be also used to better organize the different objects.
207+
====
208+
209+
== Clean up old EFI boot entries
210+
211+
Sometimes, the https://en.wikipedia.org/wiki/UEFI#UEFI_booting[UEFI boot manager] contains multiple entries for older operating systems that are probably not needed anymore (especially for host being re-provisioned multiple times).
212+
You can clean up those old entries by following any of the following procedures:
213+
214+
* Delete them on the BIOS/EFI setup interface directly (the exact procedure will depend on the hardware).
215+
* Run the UEFI https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf[`bcfg`] shell as:
216+
+
217+
----
218+
# List the entries
219+
bcfg boot dump -b
220+
# Delete entry number X
221+
bcfg boot rm X
222+
# X is the number associated the entry to remove. For example, if the entry is "Boot0002 foobar", then X is 2.
223+
----
224+
225+
* Use `efibootmgr` on a Linux system as:
226+
+
227+
----
228+
# List the entries
229+
efibootmgr -v
230+
# Delete entry number X
231+
efibootmgr -b X -B
232+
----
233+
234+
The process may leave orphaned files on the EFI System Parition (ESP), usually found under subdirectories named by the vendor (e.g., `EFI/opensuse` or `EFI/Microsoft`).
235+
While these files are generally harmless, they should be deleted if they consume excessive space as it can prevent the installation of a new OS or a boot manager update.
236+
Removal may require explicitly mounting the ESP, typically mounted as `/boot/efi/EFI` on Linux systems.

0 commit comments

Comments
 (0)