Agent-based installer - add static networking support for ISO_NO_REGISTRY mode

[bfournie]

Add TUI automation to configure static IPs and hostnames via nmtui for agent-based ISO_NO_REGISTRY installations. Creates a NEW NetworkManager connection (rather than editing the existing DHCP one) to ensure --copy-network is triggered by coreos-installer, preserving the static config across reboots.

See openshift/assisted-installer-agent#1374

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign mkowalski for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

@bfournie: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-agent-5control-ipv4	218f5e4	link	false	/test e2e-agent-5control-ipv4

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[bfournie]

This appears to work well, removing the WIP

The install was successfully

time="2026-08-03T17:18:58+02:00" level=info msg="Waiting for 5m0s ..."
time="2026-08-03T17:24:03+02:00" level=info msg="Console URL is available."
time="2026-08-03T17:24:03+02:00" level=info msg="Screenshot saved to/home/stack/dev-scripts-bfournie-latest/ocp/ostest/09-installation-progress-10.png, with type of image/png"

$ oc get nodes
NAME       STATUS   ROLES                         AGE   VERSION
master-0   Ready    control-plane,master,worker   37m   v1.36.2
master-1   Ready    control-plane,master,worker   71m   v1.36.2
master-2   Ready    control-plane,master,worker   72m   v1.36.2

And can log in via the static IP to all of the nodes

$ ssh core@192.168.111.80
Red Hat Enterprise Linux CoreOS 10.2.20260730-1
  Part of OpenShift 5.0, RHCOS is a Kubernetes-native operating system
  managed by the Machine Config Operator (`clusteroperator/machine-config`).

WARNING: Direct SSH access to machines is not recommended; instead,
make configuration changes via `machineconfig` objects:
  https://docs.openshift.com/container-platform/5.0/architecture/architecture-rhcos.html

---
Last login: Mon Aug  3 16:07:53 2026 from 192.168.111.1
[systemd]
Failed Units: 2
  NetworkManager-wait-online.service
  systemd-network-generator.service
[core@master-0 ~]$ exit
logout
Connection to 192.168.111.80 closed.
[stack@r640-u02 dev-scripts-bfournie-latest]$ ssh core@192.168.111.81
The authenticity of host '192.168.111.81 (192.168.111.81)' can't be established.
ED25519 key fingerprint is SHA256:806YjC6vkr4R/2xuwpeP3GuGAKSFQ2fVMkv6t0THmAU.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.111.81' (ED25519) to the list of known hosts.
Red Hat Enterprise Linux CoreOS 10.2.20260730-1
  Part of OpenShift 5.0, RHCOS is a Kubernetes-native operating system
  managed by the Machine Config Operator (`clusteroperator/machine-config`).

WARNING: Direct SSH access to machines is not recommended; instead,
make configuration changes via `machineconfig` objects:

[andfasano]

a little bit of bikeshedding: the name here doesn't convey properly IMHO the nature of the test. This e2e script applies the first step (by automating the agent TUI, but that's a technical detail) of a test to verify that a network config applied via agent TUI is effectively applied at the end of the installation

[andfasano]

Not strictly blocking, but I'd find really useful to have a brief description here about what the script is meant to perform: it will avoid reading all the commands one by one

[andfasano]

I am little bit confused here. In the past we implemented the the AGENT_TEST_CASES approach, with the idea of running additional e2e test cases directly within dev-scripts. The bad_dns one also focused on the agent TUI. Rather than defining a new config var, I think it would be better to keep re-using the AGENT_TEST_CASES mechanism.

As mentioned also previously, from a strict point of view of the test, what we need is:

1. Modify the network configuration of just one of the nodes, assigning a static IP different from the usual DHCP ones, using the agent TUI
2. At the end of installation, verify that the node effectively has been assigned the static IP.

A [[ $AGENT_TEST_CASES =~ "static_ip" ]] may help activating the test when required, and also adding the code where required.

[andfasano]

For what regards the e2e tests, it would be sufficient to just modify one of the nodes (maybe using an hard-coded ip). That could also help in reducing the complexity of the test code