IPI Provisioner MCP Server
Official# IPI Provisioner MCP Server
An MCP (Model Context Protocol) server for OpenShift Baremetal IPI (Installer-Provisioned Infrastructure) cluster provisioning. This tool helps you generate, validate, and manage install-config.yaml files, test BMC connectivity, validate network configurations, and guide you through the cluster installation process.
## Features
- **Install Config Management**: Generate and validate install-config.yaml files
- **BMC Testing**: Test Redfish/IPMI BMC connectivity
- **Network Validation**: Validate CIDR ranges, VIPs, and DNS configuration
- **Cluster Lifecycle**: Extract installer, create manifests, and manage installations
- **Templates**: Pre-built templates for Compact and HA deployments
## Architecture
```
ipi-provisioner-mcp/
├── mcp_server/
│ ├── config.py # Configuration and environment variables
│ ├── main.py # FastMCP server setup
│ ├── models/ # Pydantic data models
│ │ ├── install_config.py # InstallConfig models
│ │ ├── baremetal.py # Baremetal host models
│ │ └── network.py # Network configuration models
│ ├── services/ # Business logic
│ │ ├── validation_service.py # Config validation
│ │ ├── bmc_service.py # BMC operations
│ │ ├── network_service.py # Network validation
│ │ └── openshift_service.py # Installer operations
│ ├── tools/ # MCP tool implementations
│ │ ├── config_tools.py # Config generation/validation
│ │ ├── bmc_tools.py # BMC testing
│ │ ├── network_tools.py # Network validation
│ │ └── cluster_tools.py # Cluster lifecycle
│ └── utils/ # Utilities
│ ├── yaml_handler.py # YAML operations
│ └── templates.py # Template management
├── templates/ # Install-config templates
│ ├── baremetal-ipi-compact.yaml
│ └── baremetal-ipi-ha.yaml
└── tests/ # Unit tests
```
## Available MCP Tools
### Config Generation & Validation (6 tools)
1. **`validate_install_config`** - Validate install-config.yaml content
2. **`generate_install_config`** - Generate install-config.yaml from parameters
3. **`get_config_template`** - Get a pre-built template
4. **`list_config_templates`** - List all available templates
5. **`create_baremetal_host_entry`** - Create a host entry for install-config
### BMC Operations (4 tools)
1. **`test_bmc_connection`** - Test single BMC connectivity (Redfish)
2. **`validate_bmc_addresses`** - Validate multiple BMC addresses
3. **`parse_bmc_address`** - Parse and validate BMC address format
4. **`generate_bmc_test_script`** - Generate bash script for BMC testing
### Network Validation (8 tools)
1. **`validate_network_cidr`** - Validate CIDR notation
2. **`check_ip_in_network`** - Check if IP is in CIDR range
3. **`check_network_overlap`** - Check if two networks overlap
4. **`validate_vip_configuration`** - Validate VIP configuration
5. **`generate_dns_config`** - Generate DNS records for cluster
6. **`calculate_cluster_network_capacity`** - Calculate pod network capacity
7. **`generate_network_diagram`** - Generate network diagram
8. **`validate_complete_network_config`** - Comprehensive network validation
### Cluster Lifecycle (6 tools)
1. **`check_installer_binary`** - Check if openshift-install exists
2. **`extract_openshift_installer`** - Extract installer from release image
3. **`create_installation_manifests`** - Create Kubernetes manifests
4. **`prepare_cluster_installation`** - Prepare installation command
5. **`prepare_cluster_destroy`** - Prepare cluster destroy command
6. **`get_installation_status`** - Get installation status
7. **`get_installation_logs`** - Get installation logs
## Installation
```bash
cd /Users/jhajyahy/mcp/ipi-provisioner-mcp
uv sync # Creates venv and installs dependencies
source .venv/bin/activate # On Windows: .venv\Scripts\activate
```
## Configuration
### Environment Variables (Optional)
```bash
# OpenShift Configuration
export OPENSHIFT_RELEASE_IMAGE="quay.io/openshift-release-dev/ocp-release:4.17.0-x86_64"
export PULL_SECRET_PATH="$HOME/pull-secret.json"
export SSH_KEY_PATH="$HOME/.ssh/id_rsa.pub"
# MCP Transport (default: stdio)
export MCP_TRANSPORT="stdio" # or "sse" for web-based integration
export MCP_HOST="127.0.0.1" # for sse transport
export MCP_PORT="8000" # for sse transport
```
### MCP Client Configuration
#### Claude Desktop / Cursor IDE
Add to your `~/.config/claude-desktop/mcp.json` or `~/.cursor/mcp.json`:
```json
{
"mcpServers": {
"ipi-provisioner": {
"command": "uv",
"args": ["run", "python", "/Users/jhajyahy/mcp/ipi-provisioner-mcp/main.py"],
"description": "IPI Cluster Provisioning Assistant for OpenShift Baremetal",
"env": {
"OPENSHIFT_RELEASE_IMAGE": "quay.io/openshift-release-dev/ocp-release:4.17.0-x86_64",
"PULL_SECRET_PATH": "/path/to/pull-secret.json",
"SSH_KEY_PATH": "/path/to/id_rsa.pub"
}
}
}
}
```
## Usage Examples
### 1. List Available Templates
```
User: List available install-config templates
```
Response shows Compact and HA templates with descriptions.
### 2. Generate Install Config
```
User: Generate an install-config for a 3-master HA cluster named 'prod-cluster'
with base domain 'example.com', API VIP 192.168.1.10, Ingress VIP 192.168.1.11
```
### 3. Validate Install Config
```
User: Validate this install-config.yaml:
[paste your config]
```
Returns validation errors, warnings, and a summary.
### 4. Test BMC Connectivity
```
User: Test BMC connection to redfish://192.168.1.100 with username admin and password secret
```
### 5. Validate Network Configuration
```
User: Validate network config with cluster CIDR 10.128.0.0/14, service CIDR 172.30.0.0/16,
machine CIDR 192.168.1.0/24, API VIP 192.168.1.10, Ingress VIP 192.168.1.11
```
### 6. Generate DNS Configuration
```
User: Generate DNS config for cluster 'ocp' with base domain 'example.com',
API VIP 192.168.1.10, Ingress VIP 192.168.1.11, and hosts:
- master-0 with IP 192.168.1.20
- master-1 with IP 192.168.1.21
- master-2 with IP 192.168.1.22
```
This will generate A and PTR records for all cluster components including the API VIP, Ingress VIP, and all hosts.
### 7. Extract OpenShift Installer
```
User: Extract openshift-install from release image
quay.io/openshift-release-dev/ocp-release:4.17.0-x86_64
```
### 8. Check Installation Status
```
User: Get installation status for /path/to/install-dir
```
## Common Workflows
### Workflow 1: Validate Existing Config
1. Validate config: `validate_install_config(yaml_content)`
2. Validate networks: `validate_complete_network_config(...)`
3. Validate BMCs: `validate_bmc_addresses(hosts)`
4. Generate DNS config: `generate_dns_config(...)`
### Workflow 2: Troubleshoot Installation
1. Check status: `get_installation_status(install_dir)`
2. Get logs: `get_installation_logs(install_dir, lines=100)`
3. Validate network: `validate_complete_network_config(...)`
4. Test BMCs: `validate_bmc_addresses(hosts)`
## Testing
Run the test suite:
```bash
uv run pytest tests/ -v
```
## Templates
### Available Templates
1. **baremetal-ipi-compact.yaml** - Compact Cluster
- 3 master nodes (also act as workers)
- Requires API and Ingress VIPs
- Good for resource-constrained environments
2. **baremetal-ipi-ha.yaml** - High Availability
- 3 master nodes
- 2+ dedicated worker nodes
- Requires API and Ingress VIPs
- Production-ready configuration
## Network Requirements
### Machine Network
- Physical network for baremetal hosts
- Contains API VIP and Ingress VIP (for HA)
- Example: 192.168.1.0/24
### Cluster Network (Pod Network)
- Virtual network for pod-to-pod communication
- Example: 10.128.0.0/14
- Each node gets a /23 subnet (510 IPs per node)
### Service Network
- Virtual network for Kubernetes services
- Example: 172.30.0.0/16
### DNS Requirements (HA/Compact)
#### A Records
- `api.<cluster_name>.<base_domain>` → API VIP
- `*.apps.<cluster_name>.<base_domain>` → Ingress VIP (wildcard)
- `<hostname>.<base_domain>` → Host IP (for each cluster node)
#### PTR Records (Reverse DNS)
- API VIP → `api.<cluster_name>.<base_domain>`
- Each host IP → `<hostname>.<base_domain>`
Example for cluster 'ocp' with domain 'example.com':
```
# A Records
api.ocp.example.com. A 10.1.235.200
*.apps.ocp.example.com. A 10.1.235.201
master-0.example.com. A 10.1.235.25
master-1.example.com. A 10.1.235.26
master-2.example.com. A 10.1.235.27
# PTR Records
200.235.1.10.in-addr.arpa. PTR api.ocp.example.com.
25.235.1.10.in-addr.arpa. PTR master-0.example.com.
26.235.1.10.in-addr.arpa. PTR master-1.example.com.
27.235.1.10.in-addr.arpa. PTR master-2.example.com.
```
## BMC Requirements
### Supported BMC Types
- Redfish (recommended)
- Redfish Virtual Media
- IPMI
- iDRAC Virtual Media
### BMC Address Format
- Redfish: `redfish://192.168.1.100` or `redfish+https://192.168.1.100:443`
- IPMI: `ipmi://192.168.1.100`
## Troubleshooting
### Common Issues
1. **BMC Connection Failures**
- Use `test_bmc_connection` to verify connectivity
- Check BMC credentials
- Verify network connectivity to BMC
2. **Network Validation Errors**
- Use `validate_complete_network_config` to check for overlaps
- Ensure VIPs are in machine network range
- Verify DNS is configured correctly
3. **Installation Failures**
- Use `get_installation_logs` to check logs
- Verify all BMCs are reachable
- Check network configuration
- Ensure DNS records exist (for HA)
## Contributing
Contributions are welcome! Please ensure:
- All tests pass: `uv run pytest tests/ -v`
- Code follows existing patterns
- Add tests for new functionality
## License
Apache 2.0
---
**Built for OpenShift Metal Platform Team**
TDQS
Scored across 24 tools
Tools are mostly distinct, each targeting a specific task like config generation, BMC testing, network validation, or installer commands. However, test_bmc_connection and validate_bmc_addresses could be confused, though one is a live test and the other validates multiple host BMC details.
All tool names follow a consistent verb_noun pattern with lowercase and underscores, such as list_config_templates, generate_install_config, validate_vip_configuration, and get_installation_logs. The verbs vary but the pattern is uniformly applied.
24 tools is on the higher end but reasonable for the complex IPI provisioning domain, covering templates, BMC, network, and installer utilities. Some tools like parse_bmc_address and validate_network_cidr are granular, but the count is not excessive for the scope.
The tool surface covers the main lifecycle stages: config generation and validation, BMC connectivity, network checks, DNS generation, manifest creation, installation preparation, status, logs, and destroy commands. A minor gap is that actual installation execution is not performed (only the command is provided), but this is a reasonable design choice.