Skip to content

Commit e7be622

Browse files
Gagriohardys
Gagrio
authored and
hardys
committed
[SEL3-41] Documenting ironic known issue for network device naming (#762)
* SEL3-41 Documenting ironic known issue for network device naming * SEL3-41 rewording, fixes and adding an example with two secrets for network configuration * Updating wording * reordering things in the tips document
1 parent 88f598f commit e7be622

File tree

3 files changed

+120
-0
lines changed

3 files changed

+120
-0
lines changed

‎asciidoc/components/metal3.adoc‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -35,3 +35,11 @@ automated inspection, cleaning and provisioning/deprovisioning.
3535
* The upstream https://github.com/metal3-io/ip-address-manager[IP Address Management controller] is currently not supported, because it is not yet compatible with our choice of network configuration tooling.
3636
* Relatedly, the IPAM resources and Metal3DataTemplate networkData fields are not supported.
3737
* Only deployment via redfish-virtualmedia is currently supported.
38+
* It is possible to observe a network device name misalignment between the ironic python agent (IPA) and the target operating system (SL Micro 6.0/6.1), especially when trying to configure predictable names for the devices.
39+
40+
This happens because the kernel of the ironic python agent (IPA) is not currently aligned with the kernel of the target operating system (SL Micro 6.0/6.1), therefore there's a misalignment in the network drivers that allows the IPA to discover network devices in a different naming pattern than SL Micro expects.
41+
42+
There are two different approaches to be used as a workaround in the meantime:
43+
* Create two different secrets with the network configuration, one to be used with the IPA using the device names as IPA will discover and use it as `preprovisioningNetworkDataName` on the `BareMetalHost` definition and another secret with the device names as SL Micro will discover and use it as `networkData.name` on the `BareMetalHost` definition.
44+
* Use the UUIDs to reference other interfaces on the generated nmconnection files instead.
45+
More details in the link:..tips/metal3.adoc[tips and tricks] section.

‎asciidoc/quickstart/metal3.adoc‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -801,6 +801,14 @@ worker-0 available false 15m
801801
* The upstream https://github.com/metal3-io/ip-address-manager[IP Address Management controller] is currently not supported, because it's not yet compatible with our choice of network configuration tooling and first-boot toolchain in SLEMicro.
802802
* Relatedly, the IPAM resources and Metal3DataTemplate networkData fields are not currently supported.
803803
* Only deployment via redfish-virtualmedia is currently supported.
804+
* It is possible to observe a network device name misalignment between the ironic python agent (IPA) and the target operating system (SL Micro 6.0/6.1), especially when trying to configure predictable names for the devices.
805+
806+
This happens because the kernel of the ironic python agent (IPA) is not currently aligned with the kernel of the target operating system (SL Micro 6.0/6.1), therefore there's a misalignment in the network drivers that allows the IPA to discover network devices in a different naming pattern than SL Micro expects.
807+
808+
There are two different approaches to be used as a workaround in the meantime:
809+
* Create two different secrets with the network configuration, one to be used with the IPA using the device names as IPA will discover and use it as `preprovisioningNetworkDataName` on the `BareMetalHost` definition and another secret with the device names as SL Micro will discover and use it as `networkData.name` on the `BareMetalHost` definition.
810+
* Use the UUIDs to reference other interfaces on the generated nmconnection files instead.
811+
More details in the link:..tips/metal3.adoc[tips and tricks] section.
804812

805813
== Planned changes
806814

‎asciidoc/tips/metal3.adoc‎

Lines changed: 104 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,104 @@
1+
= *Metal^3^*
2+
3+
.Ironic:
4+
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:
5+
6+
_Option 1:_ Use two network configuration secrets, one for the inspection/provisioning phase and another for the deployed OS.
7+
8+
It is recommended to create two different secrets with the network configuration, one to be used with the IPA using the device names as IPA will discover and use it as `preprovisioningNetworkDataName` on the `BareMetalHost` definition and another secret with the device names as SL Micro will discover and use it as `networkData.name` on the `BareMetalHost` definition:
9+
10+
*_Example of creating two secrets, one to be used by IPA and another to be used by the target operating system_*
11+
12+
* Target OS (SL Micro) secret:
13+
14+
----
15+
apiVersion: v1
16+
kind: Secret metadata:
17+
name: controlplane-0-networkdata-os
18+
type: Opaque
19+
stringData:
20+
networkData: |
21+
interfaces:
22+
- name: enp1s0
23+
type: ethernet
24+
state: up
25+
mac-address: "00:f3:65:8a:a3:b0"
26+
ipv4:
27+
address:
28+
- ip: 192.168.125.200
29+
prefix-length: 24
30+
enabled: true
31+
dhcp: false dns-resolver:
32+
config:
33+
server:
34+
- 192.168.125.1
35+
routes:
36+
config:
37+
- destination: 0.0.0.0/0
38+
next-hop-address: 192.168.125.1
39+
next-hop-interface: enp1s0
40+
----
41+
42+
* ironic (IPA) secret:
43+
44+
----
45+
apiVersion: v1
46+
kind: Secret
47+
metadata:
48+
name: controlplane-0-networkdata-ipa
49+
type: Opaque
50+
stringData:
51+
networkData: |
52+
interfaces:
53+
- name: enp1s0np0
54+
type: ethernet
55+
state: up
56+
mac-address: "00:f3:65:8a:a3:b0"
57+
ipv4:
58+
address:
59+
- ip: 192.168.125.200
60+
prefix-length: 24
61+
enabled: true
62+
dhcp: false
63+
dns-resolver:
64+
config:
65+
server:
66+
- 192.168.125.1
67+
routes:
68+
config:
69+
- destination: 0.0.0.0/0
70+
next-hop-address: 192.168.125.1
71+
next-hop-interface: enp1s0np0
72+
----
73+
74+
* Apply on bare metal host:
75+
76+
----
77+
apiVersion: metal3.io/v1alpha1
78+
kind: BareMetalHost
79+
metadata:
80+
name: controlplane-0
81+
labels:
82+
cluster-role: control-plane
83+
spec:
84+
preprovisioningNetworkDataName: controlplane-0-networkdata-ipa
85+
networkData:
86+
name: controlplane-0-networkdata-os
87+
...
88+
89+
----
90+
91+
_Option 2:_ Alternateively, you can use UUIDs as identifiers.
92+
93+
How to get the UUIDs you need:
94+
95+
1. In your OpenSUSE or SLES machine install nmc:
96+
`zypper in nm-configurator`
97+
98+
2. then run directly:
99+
`nmc generate --config-dir /path/to/your/config --output-dir /where/you/want/it`
100+
now in the output files you should have the UUIDs that you can use in your configuration.
101+
102+
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
104+
g-dir /path/to/your/config --output-dir /where/you/want/it`

0 commit comments

Comments
 (0)