tink-cli and boots model confusion about the source of the hostname property

[rgl]

Expected Behaviour

Expected that tink hardware get would get the hostname value from the same place as Boots.

Current Behaviour

While trying to understand why Boots was not returning the hostname to the worker I've probably found some model confusion about where the hostname should be configured from.

At some point, this was the working hardware definition with the hostname set at .network.interfaces.dhcp.hostnam (I've trimmed it a bit to make it fit this issue; see the full version if required):

{
  "metadata": {
    "instance": {}
  },
  "network": {
    "interfaces": [
      {
        "dhcp": {
          "hostname": "$worker_name"
        },
      }
    ]
  }
}

But with recent Boots, we must set the hostname at .metadata.instance.hostname:

{
  "metadata": {
    "instance": {
      "hostname": "$worker_name"
    },
  },
  "network": {
    "interfaces": [
      {
        "dhcp": {
        },
      }
    ]
  }
}

But doing so has a collateral effect of making tink hardware get return an empty hostname, e.g.:

$ docker exec -i compose-tink-cli-1 tink hardware get
+--------------------------------------+-------------------+------------+----------+
| ID                                   | MAC ADDRESS       | IP ADDRESS | HOSTNAME |
+--------------------------------------+-------------------+------------+----------+
| 00000000-0000-4000-8000-080027000001 | 08:00:27:00:00:01 | 10.3.0.11  |          |
+--------------------------------------+-------------------+------------+----------+

Which was unexpected, hence this bug report.

Possible Solution

Either fix Boots or tink-cli.

Steps to Reproduce (for bugs)

1. create an hardware like described before and observe the Boots vs tink-cli behaviour.

Your Environment

• Operating System and version (e.g. Linux, Windows, MacOS): Ubuntu 20.04

• How are you running Tinkerbell? Vagrant & Libvirt.

• Link to your project or a code example to reproduce issue: https://github.com/rgl/rpi-tinkerbell-vagrant

[nshalman]

@mmlb is this one of those instances where metadata is load-bearing in spite of having not official schema?

[mmlb]

@nshalman yes :(.

[jacobweinstock]

#654 might close this. I will check Boots with the Kubernetes backend to see if this is still an issue.

[chrisdoherty4]

Given Tink CLI has been superseded and removed this is no longer an issue.