fix: day-2 compute node playbook broken for multi-arch (aarch64/x86_64/s390x) clusters

[Sravikaz]

Problem

The playbooks/create_compute_node.yaml playbook and its supporting roles have couple of bugs
that prevent successful day-2 compute node addition, particularly on multi-arch clusters
(e.g. aarch64 KVM hosts alongside s390x nodes).

Root Causes

1. roles/create_compute_node/tasks/main.yaml

• /var/www/html/bin directory not created before get_url download — task fails if directory is absent
• Nameserver kernel arg uses comma separator (nameserver=x,y) instead of correct dracut syntax (nameserver=x nameserver=y)
• Disk config always applied s390x-style options (cache=none,io=native) regardless of architecture — breaks aarch64/x86_64
• Network config always used s390x vnet instead of macvtap direct bridge for other architectures
• install_dev variable (param_compute_node.install_dev | default('vda')) was hardcoded to vda, silently ignoring the node config value
• virt-install timeout was 360s — too short for aarch64 installs, causing spurious failures

2. roles/dns_update/tasks/add.yaml

• Forward DNS zone file path used .db extension instead of .<base_domain>.zone
• Reverse DNS zone file path used .rev instead of the correct in-addr.arpa.zone with reversed IP octets
• PTR record Jinja2 syntax used .3 (invalid attribute access on a list) instead of [3] (bracket index)

3. inventories/default/group_vars/all.yaml.template

• disk_pool field missing from the day2_compute_node section — users had no template reference for this field, which is required on non-s390x architectures

Impact

• Day-2 compute node additions fail or produce nodes that never reach Ready state
• Multi-arch clusters (aarch64 KVM hosts) broken by wrong virt-install disk/network arguments
• DNS entries for new nodes written to wrong zone files, causing name resolution failures for the new node

Fix

See PR #526 — branch sravika-dev