Project

General

Profile

Actions

Bug #37368

open

Host interfaces array(s) unavailable in User Data templates during provisioning

Added by Dan Walker 14 days ago. Updated 13 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Host creation
Target version:
-
Difficulty:
Triaged:
No
Fixed in Releases:
Found in Releases:

Description

Please note, I am using Red Hat Satellite, however, I believe the issue itself may be with Foreman - apologies if incorrect.

I am attempting to build a new Host using image-based provisioning on a remote KVM/libvirtd Compute Resource, with static networks from the Interfaces tab, the same as I do now for kickstart builds. During Host creation in the UI, clicking Resolve before build shows it will only use a single Provisioning Template which is a User Data template associated with the Operating System. The OS seems to have templates for User Data and Cloud-Init in the OS edit UI, but only one is Resolved.

The template that is resolved, when previewed using the template editor, can access the normal @host.interfaces and similar arrays that the kickstart files use. When I click Submit to create the host, the VM is created, the user data is passed to it for cloud-init to pick up, but any attempts to access @host.interface macros result in None or similar. If what was in the Preview pane actually ran, I would have no issues, but as it's missing network details, it seems impossible to pass interface data to a newly provisioned VM - the only option being to rely on DHCP for boot instead and figure out the actual networking later.

For example, if I add the following to my User Data template:

        runcmd:
        - |
          echo 'interface list' > /tmp/interface_identifier_list
        <% @host.managed_interfaces.each do |interface| %>
        - |
          echo '<%= interface.identifier %> interface' >> /tmp/interface_identifier_list
        <% end %>

Then I end up with a file that just has 'interface list' in it, and nothing else, despite having multiple interfaces configured in the UI. After testing various things, I discovered that @host.provision_interface is available, but missing the MAC (generated upon build obviously). So my current workaround is as such:

write_files:
 - path: /run/network_init.sh
   content: |
     #!/bin/bash
     # <%= @host.provision_interface.identifier %> interface
     real=$(grep -l $(head -n1 $(find /sys -name address | grep <%= @host.provision_interface.identifier %>)) /sys/class/net/*/{bonding_slave/perm_hwaddr,address} 2>/dev/null | awk -F '/' '// {print $5}' | head -1)
     sanitized_real=$(echo $real | sed 's/:/_/')
     nmcli connection delete $sanitized_real &> /dev/null
     nmcli connection add type ethernet con-name $sanitized_real ifname $real ipv4.method manual ipv4.address <%= @host.provision_interface.ip %> ipv4.gateway <%= @host.provision_interface.subnet.gateway %> ipv4.dns "<%= @host.provision_interface.subnet.dns_servers.join(' ') %>" connection.autoconnect yes
     nmcli connection up $sanitized_real
   owner: 'root:root'
   permissions: '0744'

runcmd: 
 - /run/network_init.sh

It's not ideal, and as you can see I'm having to do some grep/find in /sys to get the MAC from the provision_interface.identifier, as @host.mac, @host.provision_interface.mac and so on are all empty.

Whilst the above works, it seems like a workaround, and I still have several interfaces in the Foreman UI for the host that still need to be configured. If I had access to the @host.interfaces, @host.managed_interfaces, bond_interfaces, and so on, then I wouldn't have an issue and I could set up all the interfaces upon build with ease - I spent a while figuring out this issue because the Preview pane shows what I would expect, and once the host is built if I go to the Host > Details > User Data popup, the template is rendered as I would expect, and the same for the associated /unattended endpoint.

Am I misunderstanding or mis-using this method of building? Or is there a reason that interface data is unavailable? At the least, to me, it feels like if this is by design then the rendered previews shouldn't have access to that data if it's not available at build time.

Actions #1

Updated by Dan Walker 13 days ago

I forgot to mention my versions, I'm using Satellite 6.14, which I believe has Foreman 3.7.x bundled according to https://access.redhat.com/articles/1343683

Actions

Also available in: Atom PDF