Bug 1645207
Summary: | Provisioning template kickstart_ifcfg_get_identifier_names does not produce usable interface names when interfaces are virtual | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Matthew LeSieur <matthew.lesieur> | ||||||
Component: | Provisioning Templates | Assignee: | satellite6-bugs <satellite6-bugs> | ||||||
Status: | CLOSED WONTFIX | QA Contact: | Roman Plevka <rplevka> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 6.3.4 | CC: | lzap, mhulan, oprazak | ||||||
Target Milestone: | Unspecified | Keywords: | PrioBumpQA, Triaged | ||||||
Target Release: | Unused | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2019-12-03 12:54:02 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Matthew LeSieur
2018-11-01 15:46:25 UTC
According to the product guide [1], the vlan naming scheme should be ${parent-iface}.${vlan-id}. Is there any particular reason for having a custom naming scheme instead of a documented one? When I use the documented naming, I get a different interface config which is usable (see the screenshots). It does not contain 'NAME', so I will take this as a feature request to add it. [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-configure_802_1q_vlan_tagging_using_the_command_line Created attachment 1501754 [details]
unusable vlan
Created attachment 1501755 [details]
usable vlan
Created redmine issue http://projects.theforeman.org/issues/25388 from this bug Ondřej, I may have made an incorrect assumption with a behavior that I observed with Satellite 6.3. When I added a new host to Satellite using bootstrap.py, Satellite discovered the interface identifier for the virtual interface in the format of "vlan3", not "em1.3". I used "nmcli" to add the interfaces, so I didn't directly modify the network-script files to configure the interface. An example of how I configured an interface (note, the example below is for a differet Host since the origional host is no longer available for troubleshooting): host2# nmcli connection add type vlan ifname VLAN201 dev enp6s0 id 201 ip4 10.20.30.50/24 gw4 10.20.30.1 host2# ip addr ... 2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether aa:bb:cc:dd:ee:df brd ff:ff:ff:ff:ff:ff inet6 .../64 scope link valid_lft forever preferred_lft forever ... 4: VLAN201@enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether aa:bb:cc:dd:ee:df brd ff:ff:ff:ff:ff:ff inet 10.20.30.50/24 brd 10.20.30.255 scope global noprefixroute VLAN201 valid_lft forever preferred_lft forever inet6 .../64 scope link valid_lft forever preferred_lft forever host2# cat /etc/sysconfig/network-scripts/ifcfg-vlan-VLAN201 VLAN=yes TYPE=Vlan PHYSDEV=enp6s0 VLAN_ID=201 REORDER_HDR=yes GVRP=no MVRP=no PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=none IPADDR=10.20.30.50 PREFIX=24 GATEWAY=10.20.30.1 DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=no IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=vlan-VLAN201 UUID=... DEVICE=VLAN201 ONBOOT=yes DNS1=10.20.30.2 DNS2=10.20.30.3 # hammer host interface list --host host2.example.com ----|------------|--------------------------------|-------------------|------------|------------------- ID | IDENTIFIER | TYPE | MAC ADDRESS | IP ADDRESS | DNS NAME ----|------------|--------------------------------|-------------------|------------|------------------- 200 | vlan201 | interface | | | 201 | enp7s0 | interface | aa:bb:cc:dd:ee:ff | | 199 | enp6s0 | interface (primary, provision) | aa:bb:cc:dd:ee:df | | host2.example.com ----|------------|--------------------------------|-------------------|------------|------------------- Using Satellite, re-provisioned the above host (host2) using a new Host profile in Satellite using "enp6s0.201" as the interface identifier, and I get a usable network configuration, but I still get the same "sed" error and some interesting "ifcfg-" files in /etc/sysconfig/network-scripts: host2# ls /etc/sysconfig/network-scripts/ifcfg-* /etc/sysconfig/network-scripts/ifcfg- /etc/sysconfig/network-scripts/ifcfg-enp6s0 vlan201@enp6s0 /etc/sysconfig/network-scripts/ifcfg-lo /etc/sysconfig/network-scripts/ifcfg-enp6s0 /etc/sysconfig/network-scripts/ifcfg-enp7s0 /etc/sysconfig/network-scripts/ifcfg-vlan201 host2# cat /etc/sysconfig/network-scripts/ifcfg- BOOTPROTO="none" IPADDR="10.20.30.50" NETMASK="255.255.255.0" GATEWAY="10.20.30.1" DEVICE= ONBOOT=yes PEERDNS=yes PEERROUTES=yes DEFROUTE=yes DNS1="10.20.30.2" DNS2="10.20.30.3" VLAN=yes host2# cat /etc/sysconfig/network-scripts/ifcfg-enp6s0\ vlan201@enp6s0 BOOTPROTO="none" DEVICE=enp6s0 vlan201@enp6s0 HWADDR="aa:bb:cc:dd:ee:df" ONBOOT=yes PEERDNS=no PEERROUTES=no DEFROUTE=no host2# cat /etc/sysconfig/network-scripts/ifcfg-enp6s0 TYPE=Ethernet PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=dhcp DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=enp6s0 UUID=38ccaa08-da98-45cc-a574-4d5dc2762e4e DEVICE=enp6s0 ONBOOT=no host2# cat /etc/sysconfig/network-scripts/ifcfg-vlan201 # Generated by dracut initrd NAME="vlan201" ONBOOT="yes" NETBOOT="yes" UUID="662578ad-1b85-40b3-b66a-8e53365e3da7" IPV6INIT="yes" BOOTPROTO="none" IPADDR="10.20.30.50" NETMASK="255.255.255.0" GATEWAY="10.20.30.1" TYPE="Vlan" DEVICE="vlan201" VLAN="yes" PHYSDEV="enp6s0" DNS1="10.20.30.2" VLAN_ID="201" REORDER_HDR="yes" GVRP="no" MVRP="no" PROXY_METHOD="none" BROWSER_ONLY="no" PREFIX="22" DNS2="10.20.30.3" DEFROUTE="yes" IPV4_FAILURE_FATAL="no" IPV6_AUTOCONF="yes" IPV6_DEFROUTE="yes" IPV6_FAILURE_FATAL="no" host2# nmcli connection NAME UUID TYPE DEVICE System enp6s0 vlan201@enp6s0 db1a8b97-8024-cc23-5b0e-8ef65535038c ethernet enp6s0 vlan201 662578ad-1b85-40b3-b66a-8e53365e3da7 vlan vlan201 enp6s0 38ccaa08-da98-45cc-a574-4d5dc2762e4e ethernet -- enp7s0 af930135-7a86-42ef-b2a5-926d9247ee06 ethernet -- host2# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 ... 2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether aa:bb:cc:dd:ee:df brd ff:ff:ff:ff:ff:ff inet6 .../64 scope link valid_lft forever preferred_lft forever 3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000 link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff 4: vlan201@enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether aa:bb:cc:dd:ee:df brd ff:ff:ff:ff:ff:ff inet 10.20.30.50/24 brd 10.20.30.255 scope global noprefixroute vlan201 valid_lft forever preferred_lft forever inet6 .../64 scope link noprefixroute valid_lft forever preferred_lft forever My observation of the "kickstart_ifcfg_get_identifier_names" template is it still does not produce usable interface configurations. In this case, it seems the usable configuration comes from "ifcfg-vlan201", which is apparently generated by Dracut. Is the "kickstart_ifcfg_get_identifier_names" required for RHEL 7 if Dracut configured the interface correctly? In any case, the provisioning template snippet uses an incorrect variable for the interface identifier (@identifier -> @interface.identifier). If the interface identifier is set for the Host's interface, there is no need for the provisioning template generate one on its own. satellite# rpm -qf /usr/share/foreman/app/views/unattended/provisioning_templates/snippet/_kickstart_ifcfg_get_identifier_names.erb foreman-1.15.6.48-1.el7sat.noarch Thanks Matt LeSieur Thank you for additional information. The snippet works correctly when creating new hosts directly in Satellite, but it seems to create a corrupted config when reprovisioning hosts imported with bootstrap.py. I think the script may import the interfaces in such a way that the snippet just can't figure out the correct names and deploys corrupted config. Dracut auto-created a correct config, because the one deployed by Satellite did not have a proper name. If Dracut configured the interface correctly then you can modify the template not to use the snippet as a workaround for this particular case. Ondřej, In both cases I outlined above where a host was provisioned from Satellite, I created a new host using "Host -> Create Host". I did not reuse a host profile that was already present in Satellite. I believe one of the difficulties that the snippet has is when there multiple interfaces on the server, which is always the case when a server uses tagged VLANs (e.g. eth0 and eth0.3). The "ifcfg-enp6s0\ vlan201@enp6s0" interface configuration above demonstrates how lost the script is with multiple interfaces. I have not observed these interface problems when provisioning servers using virtual machines with one interface. I also want to point out that the Puppet agent on the server is reporting the "vlan#" style interface name for a server to Satellite. The "/opt/puppetlabs/bin/facter" programs returns "vlan201" and not "enp6s0.201" for a tagged interface, which then populates server interface in Satellite. This is a whole other problem in itself, but I figure I would just point it out here since it may be relevant. I can definitely find a workaround for this problem, but ultimately, Satellite must be able to configure interfaces on a provisioned server correctly. AFAIK, tagged VLANs are not an edge case and should be handled properly by Satellite. Thanks Matt LeSieur Ondřej, I made an error in my last comment. The problem is _not_ that there are multiple interfaces on the server, but that there are multiple interfaces with the same MAC address. This situation happens with interfaces are configured for tagged VLANs. Continuing with the example above from "host2", the snippet is expecting one interface to be returned, but the code returns two interfaces: host2# ip -o link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000\ link/ether aa:bb:cc:dd:ee:df brd ff:ff:ff:ff:ff:ff 3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000\ link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff 4: vlan201@enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000\ link/ether aa:bb:cc:dd:ee:df brd ff:ff:ff:ff:ff:ff host2# ip -o link | awk '/aa:bb:cc:dd:ee:df/ {print $2;}' | sed s/:$// enp6s0 vlan201@enp6s0 Only one interface should be returned, but you can see that two are returned because both the parent and VLAN interface share the same MAC address. Thanks Matt LeSieur The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Red Hat Technical Support or your account team. If we do not hear from you, we will close this bug out. Thank you. Thanks for taking the time to look into this bug. Not many sites provision bare-metal servers anymore, so it is understandable that putting effort into fixing provisioning problems for bare-metal servers in Satellite is not a priority. Also, Dracut seems to provision the interface configuration correctly, so ultimately this problem is cosmetic. The interface configuration files that the provisioning template write can be removed manually since they do not do anything. Again, Dracut produces a working network configuration. Just to review, the three items I point out in this BZ are: 1. Dracut produces a working network configuration. Is this provisioning template snippet needed anymore? 2. The provisioning template code to produce the interface name assumes only one interface per MAC address but when a tagged VLAN is present, the host will have a parent and VLAN interface with the same MAC address. 3. Building a host from Satellite requires interface names in the format of enp6s0.201 while Puppet (facter) updates the host interface configuration using the format vlan201. The provisioning template snippet uses "ip link", which reports the interface name as vlan201@enp6s0. Thanks Matthew LeSieur Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you. Hello, this appeared when we were talking about similar bug. Let me clear some things: >The template "kickstart_ifcfg_get_identifier_names" includes an "if" statement to check if the interface identifier is defined. The code is using the wrong >variable name to check if the identifier is set. It is actually correct, the snippet you mention lives in https://github.com/theforeman/foreman/blob/b49848385eab6b500b41b0b1db5491ccdd046caf/app/views/unattended/provisioning_templates/snippet/kickstart_ifcfg_get_identifier_names.erb which is called from here https://github.com/theforeman/foreman/blob/f7e8785ba53f793ca1ab847bdeb1fa07b77da1d7/app/views/unattended/provisioning_templates/snippet/kickstart_networking_setup.erb As you can see both @interface and @identifier are passed as custom variables and the latter is used when it's virtual interface (has attached_to), for example a bond or vlan. <%- if @identifier -%> <%= "real=\"#{@identifier}\"" %> <%- else -%> This is root of the problem, when a host is created from scratch in Satellite, then interfaces has the correct relationship. In this case master-slave relationship between the regular and the virtual (VLAN) interface. Everything works fine. Now, when a host is imported using puppet facts, subscription manager or any other supported fact input, Satellite tries its best to "guess" the relationship for NICs. Both puppet facter and rhsm sends only few facts, e.g. MAC address and identifier, this does not include more detailed (netlink) information about relationships and this is on our radar to fix this in the future. However today, Satellite perform heuristic detection of these interfaces, for example identifier in the form of X.Y is seen as a VLAN interface and it attaches to the regular interface that matches the indentifier before the dot. Similarly, bondX is a bond interface etc. However, if a virutal identifier does not match the regular expression which is embedded in the Satellite codebase, it will get detected as another regular interface and this is where problem triggers. Here are the regular expressions: https://github.com/theforeman/foreman/blob/a65a7312baaf85da710be9ad98626e9a592573c3/app/services/fact_parser.rb#L3-L8 Historically, Red Hat systems VLAN identifier naming convention uses the dot dotation (eth0.42), after NetworkManager it's more common these days to use "vlan42" form where relationship is not captured. The only solution to this problem is to extend facts reported by some tools to include netlink information with relationships. Before performing provisioning, make sure the virtual interface has "attached to" set properly, has "virtual" flag and also it has the correct identifier. |