Allow to use hostname in TinkerbellTemplateConfig templating

What would you like to be added: We have the need to modify the default netplan config for Bare Metal (ubuntu), to be able to use bonding configuration with static IP assignment (we have 2 bonds, one for storage one for data traffic). We generated the TinkerbellTemplateConfig with eksctl anywhere generate tinkerbelltemplateconfig -f cluster.yaml and noticed that some templating can be used for the actions:

DEST_DISK: '{{ index .Hardware.Disks 0 }}'

Our plan is to fetch the netplan files from the admin host using curl (using a cexec action). As we need a per host based netplan, it would be nice to include the hostname in the URL through a template like the following (see CMD_LINE):

      - environment:
          BLOCK_DEVICE: '{{ formatPartition ( index .Hardware.Disks 0 ) 2 }}'
          CHROOT: "y"
          CMD_LINE: curl --output /etc/netplan/config.yaml http://ip.of.admin.host:8080/netplan/{{ .Hardware.Hostname }}.yaml && chown 0:0 /etc/netplan/config.yaml && chmod 0644 /etc/netplan/config.yaml
          DEFAULT_INTERPRETER: /bin/sh -c
          FS_TYPE: ext4
        image: public.ecr.aws/eks-anywhere/tinkerbell/hub/cexec:404dab73a8a7f33e973c6e71782f07e82b125da9-eks-a-58
        name: fetch-netplan-from-admin-host
        timeout: 90

Unfortunately, we could not find any documentation about this templating. However from the upstream code, it seems, only disks are added to the .Hardware at the moment: https://github.com/tinkerbell/tink/blob/v0.10.0/internal/workflow/reconciler.go#L134

Is this findings correct? Would it be possible to extend this struct with more information like hostname so, we can use it in TinkerbellTemplateConfig actions?

Why is this needed: Currently, we have very limited possibilities in TinkerbellTemplateConfig when it comes to a per host property that is not exposed in any way (like an IP address of a storage bond interface). Basically, this forces us to define a TinkerbellTemplateConfig per host. If the templating could be extended with per host based variables (like hostname) then, a single TinkerbellTemplateConfig could be used for many real life use cases.

Workaround in case someone run into this: Set up a VS in apache that serves the file based on source IP

# cat /etc/httpd/conf.d/eks-serving-files-vs.conf 
<VirtualHost *:8080>
  ServerName eks-a-admin01.example.com
  ServerAlias ip.of.admin.host

  DocumentRoot /var/www/html

  RewriteEngine On
  RewriteCond %{REMOTE_ADDR} 10.0.0.1
  RewriteRule ^/config\.yaml$ /var/www/html/netplan/host1.yaml
  RewriteCond %{REMOTE_ADDR} 10.0.0.2
  RewriteRule ^/config\.yaml$ /var/www/html/netplan/host2.yaml
  RewriteCond %{REMOTE_ADDR} 10.0.0.3
  RewriteRule ^/config\.yaml$ /var/www/html/netplan/host3.yaml
  RewriteCond %{REMOTE_ADDR} 10.0.0.4
  RewriteRule ^/config\.yaml$ /var/www/html/netplan/host4.yaml
  RewriteCond %{REMOTE_ADDR} 10.0.0.5
  RewriteRule ^/config\.yaml$ /var/www/html/netplan/host5.yaml
  RewriteCond %{REMOTE_ADDR} 10.0.0.6
  RewriteRule ^/config\.yaml$ /var/www/html/netplan/host6.yaml
  RewriteCond %{REMOTE_ADDR} 10.0.0.7
  RewriteRule ^/config\.yaml$ /var/www/html/netplan/host7.yaml

</VirtualHost>

Then use the following CMD_LINE: CMD_LINE: curl --output /etc/netplan/config.yaml http://ip.of.admin.host:8080/config.yaml && chown 0:0 /etc/netplan/config.yaml && chmod 0644 /etc/netplan/config.yaml

aws / eks-anywhere

Allow to use hostname in TinkerbellTemplateConfig templating #7538