In the lab, no testing happens against the ELANs until zvm-ipconf.sh runs. Because of what seemed like duplication, a lot of setup has been commented-out of the build playbooks on the assumption that there's no point in doing build-time configurations that will get zapped by zvm-ipconf. However, this disregards that the static build ELANs can (and should) be used for validation. In the event that zvm-ipconf.sh fails to run properly at post-restore firstboot, there should be just enough ELAN available for limited function and possible debugging.
Really, this has two parts:
get the ELAN services back to the point where they run in static state on the build ELANs, and
implement some additional functions in the non-TLS web interface for troubleshooting (e.g. a "break-glass" button that exposes the insecure Grafana so that Loki logs can be inspected, with the corresponding config that makes Loki functional from firstboot).
This issue will track Part A, and when that's stable we'll make another issue to tackle Part B.
In the lab, no testing happens against the ELANs until
zvm-ipconf.sh
runs. Because of what seemed like duplication, a lot of setup has been commented-out of the build playbooks on the assumption that there's no point in doing build-time configurations that will get zapped by zvm-ipconf. However, this disregards that the static build ELANs can (and should) be used for validation. In the event thatzvm-ipconf.sh
fails to run properly at post-restore firstboot, there should be just enough ELAN available for limited function and possible debugging.Really, this has two parts:
This issue will track Part A, and when that's stable we'll make another issue to tackle Part B.