A cluster name that exceeds 14 characters causes an error during bridge creation

[abhat]

Describe the bug
When we use the dev-scripts to create a cluster with a name that is longer than 14 characters it results in an error.

To Reproduce
Set the cluster name in the config_$user.sh to anything longer than 14 characters for instance: anbhat-test-bm-cluster

# Cluster name
export CLUSTER_NAME="anbhat-test-bm-cluster"

Expected/observed behavior
A cluster install succeeds with the cluster name as specified or a clear error is communicated as to what is the limitation on length of the cluster name.

Additional context

2020-10-01 17:51:32 The full traceback is:
2020-10-01 17:51:32   File "/tmp/ansible_virt_net_payload_e8j0ju69/ansible_virt_net_payload.zip/ansible/modules/cloud/misc/virt_net.py", line 628, in main
2020-10-01 17:51:32   File "/tmp/ansible_virt_net_payload_e8j0ju69/ansible_virt_net_payload.zip/ansible/modules/cloud/misc/virt_net.py", line 522, in core
2020-10-01 17:51:32   File "/tmp/ansible_virt_net_payload_e8j0ju69/ansible_virt_net_payload.zip/ansible/modules/cloud/misc/virt_net.py", line 429, in start
2020-10-01 17:51:32   File "/tmp/ansible_virt_net_payload_e8j0ju69/ansible_virt_net_payload.zip/ansible/modules/cloud/misc/virt_net.py", line 419, in create
2020-10-01 17:51:32   File "/tmp/ansible_virt_net_payload_e8j0ju69/ansible_virt_net_payload.zip/ansible/modules/cloud/misc/virt_net.py", line 217, in create
2020-10-01 17:51:32   File "/usr/lib64/python3.6/site-packages/libvirt.py", line 2990, in create
2020-10-01 17:51:32     if ret == -1: raise libvirtError ('virNetworkCreate() failed', net=self)
2020-10-01 17:51:32 failed: [localhost] (item={'name': 'anbhat-test-bm-clusterbm', 'bridge': 'anbhat-test-bm-clusterbm', 'forward_mode': 'nat', 'address_v4': '192.168.111.1', 'netmask_v4': '
255.255.255.0', 'address_v6': '', 'prefix_v6': False, 'dhcp_range_v4': ['192.168.111.20', '192.168.111.60'], 'dhcp_range_v6': [False, False], 'nat_port_range': [1024, 65535], 'domain': 'anbhat-test-bm-cluster.test.metalkube.org', 'dns': {'hosts': [{'ip': '192.168.111.5', 'hostnames': ['api']}, {'ip': '192.168.111.2', 'hostnames': ['ns1']}, {'ip': '192.168.111.1', 'hostnames': [
'virthost']}], 'forwarders': [{'domain': 'apps.anbhat-test-bm-cluster.test.metalkube.org', 'addr': '127.0.0.1'}]}}) => {
2020-10-01 17:51:32     "ansible_loop_var": "item",
2020-10-01 17:51:32     "changed": false,
2020-10-01 17:51:32     "invocation": {
2020-10-01 17:51:32         "module_args": {
2020-10-01 17:51:32             "autostart": null,
2020-10-01 17:51:32             "command": "start",
2020-10-01 17:51:32             "name": "anbhat-test-bm-clusterbm",
2020-10-01 17:51:32             "state": "active",
2020-10-01 17:51:32             "uri": "qemu:///system",
2020-10-01 17:51:32             "xml": null
2020-10-01 17:51:32         }
2020-10-01 17:51:32     },
2020-10-01 17:51:32     "item": {
2020-10-01 17:51:32         "address_v4": "192.168.111.1",
2020-10-01 17:51:32         "address_v6": "",
2020-10-01 17:51:32         "bridge": "anbhat-test-bm-clusterbm",
2020-10-01 17:51:32         "dhcp_range_v4": [
2020-10-01 17:51:32             "192.168.111.20",
2020-10-01 17:51:32             "192.168.111.60"
2020-10-01 17:51:32         ],
2020-10-01 17:51:32         "dhcp_range_v6": [
2020-10-01 17:51:32             false,
2020-10-01 17:51:32             false
2020-10-01 17:51:32         ],
2020-10-01 17:51:32         "dns": {
2020-10-01 17:51:32             "forwarders": [
2020-10-01 17:51:32                 {
2020-10-01 17:51:32                     "addr": "127.0.0.1",
2020-10-01 17:51:32                     "domain": "apps.anbhat-test-bm-cluster.test.metalkube.org"
2020-10-01 17:51:32                 }
2020-10-01 17:51:32             ],
2020-10-01 17:51:32             "hosts": [
2020-10-01 17:51:32                 {
2020-10-01 17:51:32                     "hostnames": [
2020-10-01 17:51:32                         "api"
2020-10-01 17:51:32                     ],
2020-10-01 17:51:32                     "ip": "192.168.111.5"
2020-10-01 17:51:32                 },
2020-10-01 17:51:32                 {
2020-10-01 17:51:32                     "hostnames": [
2020-10-01 17:51:32                         "ns1"
2020-10-01 17:51:32                     ],
2020-10-01 17:51:32                     "ip": "192.168.111.2"
2020-10-01 17:51:32                 },
2020-10-01 17:51:32                 {
2020-10-01 17:51:32                     "hostnames": [
2020-10-01 17:51:32                         "virthost"
2020-10-01 17:51:32                     ],
2020-10-01 17:51:32                     "ip": "192.168.111.1"
2020-10-01 17:51:32                 }
2020-10-01 17:51:32             ]
2020-10-01 17:51:32         },
2020-10-01 17:51:32         "domain": "anbhat-test-bm-cluster.test.metalkube.org",
2020-10-01 17:51:32         "forward_mode": "nat",
2020-10-01 17:51:32         "name": "anbhat-test-bm-clusterbm",
2020-10-01 17:51:32         "nat_port_range": [
2020-10-01 17:51:32             1024,
2020-10-01 17:51:32             65535
2020-10-01 17:51:32         ],
2020-10-01 17:51:32         "netmask_v4": "255.255.255.0",
2020-10-01 17:51:32         "prefix_v6": false
2020-10-01 17:51:32     },
2020-10-01 17:51:32     "msg": "error creating bridge interface anbhat-test-bm-cluster: Numerical result out of range"
2020-10-01 17:51:32 }
2020-10-01 17:51:32 

[hardys]

I'm pretty sure this is just a system limit on the interface name length so not really a dev-scripts bug, perhaps we could add some validation to limit the cluster name to avoid tripping this limit.

In the meantime, please use a shorter name ;)

[abhat]

Yes, I think I agree that this is the system limitation on the bridge name. But the naming scheme seems to append the cluster name to the bridge name i.e. "cluster-namebm". So either we can name the bridge independent of the cluster name or validate so that we don't trip. Shorter cluster-name works :).

[hardys]

Yes that's a good point @abhat another workaround is to rename the network names as they are already configurable, they just default to a prefix of the cluster name:

https://github.com/openshift-metal3/dev-scripts/blob/master/common.sh#L56

There's actually mention of this limitation in the comment there, so perhaps we should add some validation to explain the options if the limit is exceeded

[danielmellado]

I hit this same issue and was wondering, as this is a limitation from the system, if it wouldn't be just easier to cap the bridge name to 15 within the scripts.

[hardys]

I hit this same issue and was wondering, as this is a limitation from the system, if it wouldn't be just easier to cap the bridge name to 15 within the scripts.

We can't truncate the network names, as the last two characters are the unique part e.g ${CLUSTER_NAME}bm

Perhaps we should add a validation which fails if CLUSTER_NAME is more than 13 characters instead?

The validation error can also mention it's possible to override *NETWORK_NAME if someone really needs a long cluster name for some reason.