Having two separate fields for a label/hostname never made much sense.
In our database, we don't have any cases were the label and ssh_host
fields are set to different values. In most cases only ssh_host is set.
Remove the ssh_host field, only keep the label field for the hostname.
A data migration step copies the ssh_host value to the label field. As a
side benefit, this will ensure that all infrastructure hosts are
displayed with their hostname instead of ISD-AS,IP in the admin panel.
In the api/topology json, the host name is still called ssh_host.
We can rename this later, combined with other API breaking changes.
Having two separate fields for a label/hostname never made much sense. In our database, we don't have any cases were the label and ssh_host fields are set to different values. In most cases only ssh_host is set.
Remove the ssh_host field, only keep the label field for the hostname.
A data migration step copies the ssh_host value to the label field. As a side benefit, this will ensure that all infrastructure hosts are displayed with their hostname instead of ISD-AS,IP in the admin panel.
In the api/topology json, the host name is still called
ssh_host
. We can rename this later, combined with other API breaking changes.This change is