MGMT-22968: Add infrastructure-only mode and Landing Zone VM support

Add new 'infra_only' Makefile target and Landing Zone VM support to
dev-scripts, enabling creation of baremetal-like test infrastructure
without deploying an OpenShift cluster.

Changes:

1. New 'infra_only' Makefile target
   - Runs 'requirements' and 'configure' steps only
   - Stops before cluster deployment (build_installer, ironic, etc.)
   - Useful for testing external deployment tools

2. Landing Zone VM support
   - Added NUM_LANDINGZONE environment variable (default: 0)
   - Configurable specs: LANDINGZONE_MEMORY (8192 MB), LANDINGZONE_DISK
     (60 GB), LANDINGZONE_VCPU (4)
   - Landing Zone VM has dual network access (BMC and cluster networks)
   - Worker VMs use cluster network only when NUM_LANDINGZONE > 0

3. NetworkManager connection handling fix
   - Fixed nmcli error when cluster network is managed by libvirt
   - Suppress error if NetworkManager connection doesn't exist:
     sudo nmcli con del ${BAREMETAL_NETWORK_NAME} 2>/dev/null || true
   - Prevents make infra_only from failing in CI pipelines

4. Documentation
   - Added "Infrastructure-Only Mode" section to README
   - Added "Deploying with Landing Zone VMs" section to README

Use case: Testing external deployment tools (e.g., GoRI Lab) that need
infrastructure without cluster deployment.

Backward compatibility: All existing targets work unchanged. New variables
default to 0 (no Landing Zone VMs).

Author: eliorerz

02_configure_host.sh

@@ -161,6 +161,46 @@ if ! [[ -f /usr/share/OVMF/OVMF_CODE.fd || -L /usr/share/OVMF/OVMF_CODE.fd ]]; t
   sudo ln -s /usr/share/edk2/ovmf/OVMF_CODE.fd /usr/share/OVMF/
 fi
 
+# Fix network topology for Landing Zone use case:
+# Cluster node VMs (masters/workers) should only have cluster network (baremetal network)
+# Landing Zone VMs should have both BMC network (provisioning network) and cluster network
+# This is necessary because metal3-dev-env attaches all networks to all VMs
+if [ ${NUM_LANDINGZONE:-0} -gt 0 ]; then
+  echo "Configuring network topology: removing BMC network from cluster node VMs..."
+
+  # Remove BMC network from master VMs
+  for i in $(seq 0 $((NUM_MASTERS - 1))); do
+    vm_name="${CLUSTER_NAME}_master_${i}"
+    # Get MAC address of the interface connected to provisioning network (BMC network)
+    # The MAC line comes BEFORE the source bridge line in the XML
+    bmc_mac=$(sudo virsh dumpxml "$vm_name" | grep -B 1 "bridge='${PROVISIONING_NETWORK_NAME}'" | grep "mac address" | sed "s/.*address='\([^']*\)'.*/\1/")
+
+    if [ -n "$bmc_mac" ]; then
+      echo "  Removing BMC interface (MAC: $bmc_mac) from $vm_name"
+      sudo virsh detach-interface "$vm_name" bridge --mac "$bmc_mac" --config --persistent
+    else
+      echo "  Warning: Could not find BMC interface for $vm_name (may already be removed)"
+    fi
+  done
+
+  # Remove BMC network from worker VMs
+  for i in $(seq 0 $((NUM_WORKERS - 1))); do
+    vm_name="${CLUSTER_NAME}_worker_${i}"
+    # Get MAC address of the interface connected to provisioning network (BMC network)
+    # The MAC line comes BEFORE the source bridge line in the XML
+    bmc_mac=$(sudo virsh dumpxml "$vm_name" | grep -B 1 "bridge='${PROVISIONING_NETWORK_NAME}'" | grep "mac address" | sed "s/.*address='\([^']*\)'.*/\1/")
+
+    if [ -n "$bmc_mac" ]; then
+      echo "  Removing BMC interface (MAC: $bmc_mac) from $vm_name"
+      sudo virsh detach-interface "$vm_name" bridge --mac "$bmc_mac" --config --persistent
+    else
+      echo "  Warning: Could not find BMC interface for $vm_name (may already be removed)"
+    fi
+  done
+
+  echo "Network topology configured: cluster nodes have cluster network only, landing zone has both networks"
+fi
+
 if [ ${NUM_EXTRA_WORKERS} -ne 0 ]; then
   ORIG_NODES_FILE="${NODES_FILE}.orig"
   cp -f ${NODES_FILE} ${ORIG_NODES_FILE}
@@ -315,7 +355,8 @@ if [ "$MANAGE_BR_BRIDGE" == "y" ] ; then
     # have some delay between disabling the network on libvirt
     # and deleting it from NM to avoid race conditions
     sleep 1
-    sudo nmcli con del ${BAREMETAL_NETWORK_NAME}
+    # Delete NetworkManager connection if it exists (ignore error if it doesn't)
+    sudo nmcli con del ${BAREMETAL_NETWORK_NAME} 2>/dev/null || true
     # have some delay between deleting the network on NM
     # and restarting it from libvirt to avoid race conditions
     sleep 1

Makefile

@@ -1,4 +1,4 @@
-.PHONY: default all agent agent_cleanup agent_build_installer agent_configure agent_create_cluster requirements configure ironic ocp_run install_config clean ocp_cleanup ironic_cleanup host_cleanup cache_cleanup registry_cleanup proxy_cleanup workingdir_cleanup podman_cleanup bell
+.PHONY: default all agent agent_cleanup agent_build_installer agent_configure agent_create_cluster infra_only requirements configure ironic ocp_run install_config clean ocp_cleanup ironic_cleanup host_cleanup cache_cleanup registry_cleanup proxy_cleanup workingdir_cleanup podman_cleanup bell
 default: requirements configure build_installer ironic install_config ocp_run bell
 
 all: default
@@ -13,6 +13,19 @@ agent: agent_requirements requirements configure agent_build_installer agent_pre
 # Requires at least 1 extra worker node to be configured with disk size at least 100Gß
 agent_plus_add_node: agent agent_add_extraworker_nodes
 
+# Setup infrastructure only (VMs, networks, BMC emulation) without cluster deployment
+# Useful for testing external deployment tools
+infra_only: requirements configure
+	@echo "Infrastructure setup complete!"
+	@echo "  - VMs created and configured"
+	@echo "  - Networks configured (provisioning + baremetal)"
+	@echo "  - BMC emulation running (virtualbmc + sushy-tools)"
+	@echo ""
+	@echo "Skipping cluster installation. You can now:"
+	@echo "  - Deploy OpenShift using your own tooling"
+	@echo "  - Access BMC endpoints via Redfish/IPMI"
+	@echo "  - Use 'make clean' to tear down infrastructure"
+
 agent_requirements:
 	./agent/01_agent_requirements.sh
 

README.md

@@ -222,6 +222,29 @@ Then you can interact with the k8s API on the bootstrap VM e.g
 You can also see the status of the bootkube.sh script which is running via
 `journalctl -b -f -u bootkube.service`.
 
+## Infrastructure-Only Mode
+
+For testing external deployment tools or custom installers, you can use the `infra_only` target to create just the infrastructure without deploying an OpenShift cluster:
+
+```
+make infra_only
+```
+
+This will:
+- Create libvirt VMs with configured specs
+- Set up networking (provisioning + baremetal networks)
+- Configure BMC emulation (virtualbmc + sushy-tools)
+- Stop before cluster deployment
+
+This is useful when you want to:
+- Test external deployment tools (e.g., GoRI Lab, custom installers)
+- Use the infrastructure for development without deploying OpenShift
+- Have full control over the cluster installation process
+
+After running `make infra_only`, you can deploy OpenShift using your own tooling and access the BMC endpoints via Redfish (port 8000) or IPMI (ports 6230+).
+
+To clean up the infrastructure, use `make clean`.
+
 ## Interacting with the deployed cluster
 
 Consider `export KUBECONFIG=<path-to-config>` to avoid using the `--kubeconfig` flag on each command.
@@ -452,6 +475,33 @@ in `config_$USER.sh` (check `config_example.sh` for recommended defaults):
 #export WORKER_VCPU=4
 ```
 
+### Deploying with Landing Zone VMs
+
+Landing Zone VMs are special-purpose VMs that have access to both the BMC (provisioning)
+and cluster (baremetal) networks. They are useful as deployment hosts for external
+tooling that needs to manage worker nodes via BMC while also having access to the
+cluster network.
+
+To create Landing Zone VMs, set the following in `config_$USER.sh`:
+
+```
+# Create 1 Landing Zone VM
+export NUM_LANDINGZONE=1
+
+# Customize Landing Zone VM resources (optional)
+export LANDINGZONE_MEMORY=8192  # 8 GB RAM
+export LANDINGZONE_DISK=60      # 60 GB disk
+export LANDINGZONE_VCPU=4       # 4 vCPUs
+```
+
+Network topology when using Landing Zone VMs:
+- **Worker VMs**: Cluster network only (BMC network interface is automatically removed)
+- **Landing Zone VMs**: Both BMC and cluster networks (dual-network access)
+- **BMC emulation**: Runs on the host machine, accessible via the BMC network
+
+This topology ensures proper network isolation while allowing the Landing Zone VM
+to act as a bridge for deployment tools.
+
 ### Testing custom container images
 dev-scripts uses an openshift release image that contains references to openshift
 containers, any of these containers can be overridden by setting environment

common.sh

@@ -275,6 +275,7 @@ export NUM_MASTERS=${NUM_MASTERS:-"3"}
 export NUM_WORKERS=${NUM_WORKERS:-"2"}
 export NUM_ARBITERS=${NUM_ARBITERS:-"0"}
 export NUM_EXTRA_WORKERS=${NUM_EXTRA_WORKERS:-"0"}
+export NUM_LANDINGZONE=${NUM_LANDINGZONE:-"0"}
 export EXTRA_WORKERS_ONLINE_STATUS=${EXTRA_WORKERS_ONLINE_STATUS:-"true"}
 export EXTRA_WORKERS_NAMESPACE=${EXTRA_WORKERS_NAMESPACE:-"openshift-machine-api"}
 export VM_EXTRADISKS=${VM_EXTRADISKS:-"false"}
@@ -284,6 +285,7 @@ export MASTER_HOSTNAME_FORMAT=${MASTER_HOSTNAME_FORMAT:-"master-%d"}
 export ARBITER_HOSTNAME_FORMAT=${ARBITER_HOSTNAME_FORMAT:-"arbiter-%d"}
 export WORKER_HOSTNAME_FORMAT=${WORKER_HOSTNAME_FORMAT:-"worker-%d"}
 export EXTRA_WORKER_HOSTNAME_FORMAT=${EXTRA_WORKER_HOSTNAME_FORMAT:-"extraworker-%d"}
+export LANDINGZONE_HOSTNAME_FORMAT=${LANDINGZONE_HOSTNAME_FORMAT:-"landingzone-%d"}
 
 export MASTER_MEMORY=${MASTER_MEMORY:-16384}
 export MASTER_DISK=${MASTER_DISK:-60}
@@ -301,6 +303,10 @@ export EXTRA_WORKER_MEMORY=${EXTRA_WORKER_MEMORY:-${WORKER_MEMORY}}
 export EXTRA_WORKER_DISK=${EXTRA_WORKER_DISK:-${WORKER_DISK}}
 export EXTRA_WORKER_VCPU=${EXTRA_WORKER_VCPU:-${WORKER_VCPU}}
 
+export LANDINGZONE_MEMORY=${LANDINGZONE_MEMORY:-8192}
+export LANDINGZONE_DISK=${LANDINGZONE_DISK:-60}
+export LANDINGZONE_VCPU=${LANDINGZONE_VCPU:-4}
+
 # Ironic vars (Image can be use <NAME>_LOCAL_IMAGE to override)
 export IRONIC_IMAGE=${IRONIC_IMAGE:-"quay.io/metal3-io/ironic:main"}
 export IRONIC_DATA_DIR="${WORKING_DIR}/ironic"
@@ -310,7 +316,7 @@ export IRONIC_IMAGES_DIR="${IRONIC_DATA_DIR}/html/images"
 export VBMC_IMAGE=${VBMC_IMAGE:-"quay.io/metal3-io/vbmc"}
 export SUSHY_TOOLS_IMAGE=${SUSHY_TOOLS_IMAGE:-"quay.io/metal3-io/sushy-tools"}
 export VBMC_BASE_PORT=${VBMC_BASE_PORT:-"6230"}
-export VBMC_MAX_PORT=$((VBMC_BASE_PORT + NUM_MASTERS + NUM_ARBITERS + NUM_WORKERS + NUM_EXTRA_WORKERS - 1))
+export VBMC_MAX_PORT=$((VBMC_BASE_PORT + NUM_MASTERS + NUM_ARBITERS + NUM_WORKERS + NUM_EXTRA_WORKERS + NUM_LANDINGZONE - 1))
 export REDFISH_EMULATOR_IGNORE_BOOT_DEVICE="${REDFISH_EMULATOR_IGNORE_BOOT_DEVICE:-False}"
 
 # Which docker registry image should we use?

vm_setup_vars.yml

@@ -11,6 +11,7 @@ num_masters: 3
 num_workers: 1
 num_arbiters: "{{ lookup('env', 'NUM_ARBITERS') | default(0) }}"
 num_extraworkers: 0
+num_landingzones: "{{ lookup('env', 'NUM_LANDINGZONE') | default(0) }}"
 extradisks_list: "{{ lookup('env', 'VM_EXTRADISKS_LIST').split(' ') | default(['vdb']) }}"
 extradisks_size: "{{ lookup('env', 'VM_EXTRADISKS_SIZE') | default(['8G']) }}"
 flavors:
@@ -42,6 +43,13 @@ flavors:
     extradisks: "{{ lookup('env', 'VM_EXTRADISKS') | default(false) }}"
     architecture: "{{ libvirt_arch }}"
 
+  landingzone:
+    memory: "{{ lookup('env', 'LANDINGZONE_MEMORY') | default('8192') }}"
+    disk: "{{ lookup('env', 'LANDINGZONE_DISK') | default('60') }}"
+    vcpu: "{{ lookup('env', 'LANDINGZONE_VCPU') | default('4') }}"
+    extradisks: "{{ lookup('env', 'VM_EXTRADISKS') | default(false) }}"
+    architecture: "{{ libvirt_arch }}"
+
 # For OpenShift we create some additional DNS records for the API/DNS VIPs
 baremetal_network_cidr_v4: "{{ lookup('env', 'EXTERNAL_SUBNET_V4') }}"
 baremetal_network_cidr_v6: "{{ lookup('env', 'EXTERNAL_SUBNET_V6') }}"