|
| 1 | +# SNO-NXSW Scenario |
| 2 | + |
| 3 | +## Overview |
| 4 | + |
| 5 | +The `sno-veos` scenario is a Single Node OpenShift (SNO) deployment scenario |
| 6 | +for HotStack that deploys OpenStack on OpenShift with ironic bare metal |
| 7 | +provisioning capabilities and network switch integration. |
| 8 | + |
| 9 | +## Architecture |
| 10 | + |
| 11 | +This scenario provisions: |
| 12 | + |
| 13 | +- **1x Controller Node**: Management and DNS/DHCP services |
| 14 | +- **1x OpenShift Master Node**: Single node OpenShift cluster running OpenStack services |
| 15 | +- **1x Switch Node**: vEOS Lab switch with trunk ports for tenant VLAN networks |
| 16 | +- **2x Ironic Nodes**: Virtual bare metal nodes for testing Ironic provisioning workflows |
| 17 | + |
| 18 | +## Features |
| 19 | + |
| 20 | +- **Complete OpenStack Stack**: Full OpenStack deployment with ironic bare |
| 21 | + metal service |
| 22 | +- **Network Switch Integration**: Automated switch configuration with |
| 23 | + Zero Prov (??? Arista vEOS) and NGS (Networking Generic Switch) |
| 24 | +- **Complete Networking**: All OpenStack service networks with dedicated |
| 25 | + ironic networks |
| 26 | +- **SNO Deployment**: Single node OpenShift optimized for OpenStack services |
| 27 | +- **Development Ready**: Ideal for testing and development environments |
| 28 | +- **Bare Metal Provisioning**: Ironic service with 2 nodes for testing bare |
| 29 | + metal workflows |
| 30 | + |
| 31 | +## Networks |
| 32 | + |
| 33 | +- **machine-net**: 192.168.32.0/24 - External access network |
| 34 | +- **ctlplane-net**: 192.168.122.0/24 - Control plane network |
| 35 | +- **internal-api-net**: 172.17.0.0/24 - OpenStack internal API network |
| 36 | +- **storage-net**: 172.18.0.0/24 - Storage network |
| 37 | +- **tenant-net**: 172.19.0.0/24 - Tenant network for OpenStack workloads |
| 38 | +- **ironic-net**: 172.20.1.0/24 - Ironic network for bare metal provisioning |
| 39 | +- **tenant-vlan103**: 172.20.3.0/24 - Tenant VLAN network (VLAN 103) |
| 40 | +- **tenant-vlan104**: 172.20.4.0/24 - Tenant VLAN network (VLAN 104) |
| 41 | +- **ironic0-br-net**: 172.20.5.0/29 - Ironic0 bridge network |
| 42 | +- **ironic1-br-net**: 172.20.5.8/29 - Ironic1 bridge network |
| 43 | + |
| 44 | +## Switch Instance Configuration |
| 45 | + |
| 46 | +The switch instance provides network switching capabilities with the following |
| 47 | +interface configuration: |
| 48 | + |
| 49 | +### Network Interface Summary |
| 50 | + |
| 51 | +```text |
| 52 | +Switch Instance: |
| 53 | +├── eth0: machine-net (management interface) |
| 54 | +├── eth1: trunk (ironic:101, tenant-vlan103:103, tenant-vlan104:104) |
| 55 | +├── eth2: ironic0-br-net (ironic bridge network) |
| 56 | +└── eth3: ironic1-br-net (ironic bridge network) |
| 57 | +``` |
| 58 | + |
| 59 | +### VLAN Mapping |
| 60 | + |
| 61 | +- **VLAN 101**: ironic (172.20.1.0/24) |
| 62 | +- **VLAN 102**: Default native VLAN |
| 63 | +- **VLAN 103**: tenant-vlan103 (172.20.3.0/24) |
| 64 | +- **VLAN 104**: tenant-vlan104 (172.20.4.0/24) |
| 65 | + |
| 66 | +The switch uses the `nxsw` image and provides dual trunk ports for redundancy |
| 67 | +and high availability. |
| 68 | + |
| 69 | +### POAP (Power-On Auto Provisioning) |
| 70 | + |
| 71 | +POAP is a Cisco NX-OS feature that automates the initial configuration of |
| 72 | +network switches. When the switch boots up, it automatically: |
| 73 | + |
| 74 | +1. **Downloads Configuration**: Fetches the switch configuration from a |
| 75 | + TFTP/HTTP server |
| 76 | +2. **Applies Settings**: Automatically configures interfaces, VLANs, and |
| 77 | + network settings |
| 78 | +3. **Enables Services**: Activates required network services (NETCONF, LACP, LLDP) |
| 79 | +4. **Validates Setup**: Performs integrity checks using MD5 checksums |
| 80 | + |
| 81 | +In this scenario, POAP enables zero-touch deployment of the NX-OS switch with pre-configured: |
| 82 | + |
| 83 | +- **Interface Configuration**: Trunk and access ports for tenant VLANs |
| 84 | +- **VLAN Setup**: VLANs for network segmentation |
| 85 | +- **Management Settings**: IP addressing, DNS, and routing configuration |
| 86 | +- **Security**: User accounts and access control |
| 87 | + |
| 88 | +## Ironic Nodes |
| 89 | + |
| 90 | +The scenario includes 2 virtual bare metal nodes for testing Ironic provisioning: |
| 91 | + |
| 92 | +### Ironic Node 0 |
| 93 | + |
| 94 | +- **Network**: ironic0-br-net (172.20.5.0/29) |
| 95 | +- **Purpose**: Bare metal provisioning testing |
| 96 | +- **Configuration**: Virtual media boot capable with sushy-tools |
| 97 | + |
| 98 | +### Ironic Node 1 |
| 99 | + |
| 100 | +- **Network**: ironic1-br-net (172.20.5.8/29) |
| 101 | +- **Purpose**: Bare metal provisioning testing |
| 102 | +- **Configuration**: Virtual media boot capable with sushy-tools |
| 103 | + |
| 104 | +## Usage |
| 105 | + |
| 106 | +This scenario is ideal for: |
| 107 | + |
| 108 | +- Testing OpenStack deployments with neutron ML2 plugins |
| 109 | +- Validating bare metal provisioning workflows with Ironic |
| 110 | +- Network switch integration testing with OpenStack |
| 111 | +- Development and testing of networking-generic-switch functionality |
| 112 | + |
| 113 | +## Files |
| 114 | + |
| 115 | +- `bootstrap_vars.yml`: Main configuration variables |
| 116 | +- `heat_template.yaml`: OpenStack Heat template for infrastructure |
| 117 | +- `automation-vars.yml`: Automation pipeline definition |
| 118 | +- `manifests/`: OpenShift/Kubernetes manifests |
| 119 | +- `test-operator/`: Test automation configuration |
| 120 | + |
| 121 | +## Upload switch image to cloud |
| 122 | + |
| 123 | +```bash |
| 124 | + openstack image create vEOS-lab-4.34.1F \ |
| 125 | + --disk-format qcow2 \ |
| 126 | + --file vEOS-lab-4.34.1F.qcow2 \ |
| 127 | + --property hw_video_model=none |
| 128 | +``` |
| 129 | + |
| 130 | +## Deployment |
| 131 | + |
| 132 | +Follow the standard HotStack deployment process with this scenario by setting |
| 133 | +the scenario name to `sno-veos` in your deployment configuration. |
0 commit comments