WIP

  gather_facts: true

  pre_tasks:

    - name: Load group variables

      ansible.builtin.include_vars:

        file: "{{ playbook_dir }}/../../group_vars/all.yml"

    - name: Set kubeconfig path for remote deployment

      ansible.builtin.set_fact:

  gather_facts: true

  pre_tasks:

    - name: Load group variables

      ansible.builtin.include_vars:

        file: "{{ playbook_dir }}/../../group_vars/all.yml"

    - name: Set kubeconfig path for remote deployment

      ansible.builtin.set_fact:

  gather_facts: true

  pre_tasks:

    - name: Load group variables

      ansible.builtin.include_vars:

        file: "{{ playbook_dir }}/../../../group_vars/all.yml"

    - name: Display playbook information

      ansible.builtin.debug:

      private: false

  pre_tasks:

    - name: Load group variables

      ansible.builtin.include_vars:

        file: "{{ playbook_dir }}/../../../group_vars/all.yml"

    - name: Update kubeconfig path for remote deployment

      ansible.builtin.set_fact:

# Deployment Scenarios

This directory contains end-to-end deployment scenarios for the Open Operator Platform (OOP). Each scenario serves a specific use case and is organized into its own subdirectory with standardized playbook names.

## Directory Structure

```

scenarios/

├── README.md

├── full_oop/          # Complete single operator platform (production)

│   ├── deploy.yml

│   ├── graceful_undeploy.yml

│   └── quick_undeploy.yml

│

├── all_in_one/        # Federation testing on single cluster (development)

│   ├── deploy.yml

│   ├── graceful_undeploy.yml

│   └── quick_undeploy.yml

│

└── dual_oop/          # Real multi-operator federation (production)

    ├── deploy.yml

    ├── graceful_undeploy.yml

    └── quick_undeploy.yml

```

## Scenarios Overview

### 1. Full OOP (Production Single Operator)

**Purpose**: Deploy a complete, production-ready Operator Platform for a single operator.

**What it includes:**

- Infrastructure: Kind cluster, Prometheus monitoring, Node Feature Discovery

- Core OOP Modules: Zot registry, Artefact Manager, SRM, OEG

- Federation: **Single Federation Manager** (no federation testing)

- Supporting Services: Homer dashboard

- Edge Platform: Lite2Edge

**Target Inventory:** `kind_cluster` group

**Use Cases:**

- Production deployment for a single operator

- Operator wants full OOP capabilities without federation

- Simplest production-ready configuration

**Playbooks:**

```bash

# Deploy complete OOP with single FM

ansible-playbook playbooks/scenarios/full_oop/deploy.yml -e @secrets.yml

# Graceful undeploy (component by component)

ansible-playbook playbooks/scenarios/full_oop/graceful_undeploy.yml

# Quick undeploy (delete cluster)

ansible-playbook playbooks/scenarios/full_oop/quick_undeploy.yml

```

### 2. All-in-One (Federation Development/Testing)

**Purpose**: Test federation features on a single cluster with dual Federation Managers simulating two federated operators.

**What it includes:**

- Infrastructure: Kind cluster, Prometheus, Node Feature Discovery

- Core OOP Modules: Zot, Artefact Manager, SRM, OEG

- Federation: **TWO Federation Managers** (federation-manager + federation-manager-remote)

  - Separate Kubernetes namespaces

  - Separate Keycloak realms

  - Separate MongoDB instances

  - Different NodePorts

- Supporting Services: Homer dashboard

- Edge Platform: Lite2Edge (shared between both FMs)

**Target Inventory:** `kind_cluster` group

**Use Cases:**

- Developing and testing federation features

- Testing multi-operator scenarios without needing multiple hosts

- CI/CD testing of federation logic

- Learning how federation works

**Key Configuration:**

- `federation-manager` namespace: Primary FM

- `federation-manager-remote` namespace: Secondary FM (simulates remote operator)

- Both FMs configured to use lite2edge as ECP client

- Different ports and credentials for each FM

**Playbooks:**

```bash

# Deploy all-in-one with dual FMs

ansible-playbook playbooks/scenarios/all_in_one/deploy.yml -e @secrets.yml

# Graceful undeploy (removes both FMs properly)

ansible-playbook playbooks/scenarios/all_in_one/graceful_undeploy.yml

# Quick undeploy

ansible-playbook playbooks/scenarios/all_in_one/quick_undeploy.yml

```

### 3. Dual OOP (Real Multi-Operator Federation)

**Purpose**: Deploy two complete, independent Operator Platforms on separate hosts for real production federation scenarios.

**What it includes (per OOP):**

- Infrastructure: Kind cluster (op1/op2), Prometheus, Node Feature Discovery

- Core OOP Modules: Zot, Artefact Manager, SRM, OEG

- Federation: One Federation Manager per OOP

- Supporting Services: Homer dashboard

- Edge Platform: Lite2Edge

**Target Inventory:**

- `op1_nodes` group (first platform, e.g., openop_3)

- `op2_nodes` group (second platform, e.g., openop_2)

**Use Cases:**

- Production multi-operator federation

- Testing real network federation (different hosts/networks)

- Multi-tenant operator scenarios

- High-availability testing

**Configuration:**

- Each OOP gets unique cluster name (op1, op2)

- Each OOP uses distinct kubeconfig files

- Both OOPs use default ports (separate VMs = no conflicts)

- Federation Managers configured to federate across hosts

**Playbooks:**

```bash

# Deploy both OOPs

ansible-playbook playbooks/scenarios/dual_oop/deploy.yml -e @secrets.yml

# Deploy only OP1 (using tags)

ansible-playbook playbooks/scenarios/dual_oop/deploy.yml -e @secrets.yml --tags op1

# Deploy only OP2 (using tags)

ansible-playbook playbooks/scenarios/dual_oop/deploy.yml -e @secrets.yml --tags op2

# Graceful undeploy both

ansible-playbook playbooks/scenarios/dual_oop/graceful_undeploy.yml

# Quick undeploy both

ansible-playbook playbooks/scenarios/dual_oop/quick_undeploy.yml

# Quick undeploy only OP1

ansible-playbook playbooks/scenarios/dual_oop/quick_undeploy.yml --tags op1

```

## Comparison: Which Scenario Should I Use?

| Feature | Full OOP | All-in-One | Dual OOP |

|---------|----------|------------|----------|

| **Number of Hosts** | 1 | 1 | 2 |

| **Federation Managers** | 1 | 2 (simulated) | 2 (real) |

| **Use Case** | Production single operator | Federation testing | Production federation |

| **Complexity** | Low | Medium | High |

| **Setup Time** | Fast | Fast | Slower |

| **Resource Usage** | Low | Medium | High |

| **Real Federation** | No | No (simulated) | Yes |

| **Best For** | Single operator production | Development/testing | Multi-operator production |

## Playbook Naming Convention

All scenarios follow this standard naming pattern:

- **`deploy.yml`** - Main deployment playbook

- **`graceful_undeploy.yml`** - Component-by-component removal (uses role undeploy tasks)

- **`quick_undeploy.yml`** - Fast removal (deletes Kind cluster directly)

## Choosing Between Graceful vs Quick Undeploy

### Graceful Undeploy

**When to use:**

- You want to preserve cluster state for debugging

- You need to verify each component uninstalls correctly

- You're testing the undeploy logic of individual roles

- You want to ensure proper cleanup of external resources (PVs, network, etc.)

**Characteristics:**

- Takes longer (removes each component individually)

- Uses role-based undeploy tasks with state management

- Allows for component-level debugging

- Safer for production-like environments

### Quick Undeploy

**When to use:**

- You need to quickly tear down and rebuild

- You're doing rapid iteration/testing

- You don't care about graceful component removal

- You want to reset to a clean state immediately

**Characteristics:**

- Very fast (deletes entire Kind cluster)

- Minimal cleanup logic

- May leave some orphaned resources

- Best for development/testing environments

## Prerequisites

Before running any scenario, ensure:

1. **Inventory is configured** (`ansible/inventory/hosts`)

   - `kind_cluster` group for full_oop and all_in_one

   - `op1_nodes` and `op2_nodes` groups for dual_oop

2. **Secrets file exists** (`ansible/secrets.yml`)

   - Contains sensitive variables (passwords, tokens, etc.)

   - **NEVER** commit this file to version control

3. **Virtual environment is activated**

   ```bash

   cd ansible

   source venv/bin/activate

   ```

4. **SSH access is configured**

   - SSH keys loaded for target hosts

   - Passwordless sudo access (or use `-K` flag)

5. **Group variables are configured** (`ansible/group_vars/all/`)

   - Review and adjust component-specific variables as needed

   - See `ansible/group_vars/README.md` for details

## Deployment Modes

All scenarios support two deployment modes:

### Local Mode (Default)

Ansible runs on the same machine where OOP is deployed.

- Kubeconfig stored locally in `{{ op_automation_base }}/automation/<cluster_name>/`

- Uses `kubectl` from local machine

### Remote Mode

Ansible runs from a control node, deploys to remote hosts.

- Set `deployment_mode: remote` in variables or command line

- Kubeconfig stored on remote host in `/home/<user>/kind-cluster-config/`

- Uses `kubectl` from remote host

**Example:**

```bash

ansible-playbook playbooks/scenarios/full_oop/deploy.yml \

  -e @secrets.yml \

  -e deployment_mode=remote

```

## Common Variables

Key variables you might want to override:

```bash

# Cluster configuration

-e recreate_cluster=yes              # Force recreate Kind cluster

-e kind_cluster_name=custom-name     # Custom cluster name

-e worker_nodes=2                    # Number of worker nodes

# Storage

-e prepare_oop_storage=true          # Enable OOP storage (required for OEG/SRM)

# Federation Manager (for full_oop scenario)

-e federation_manager_ecp_client_name=lite2edge    # ECP client to use

-e federation_manager_ecp_port=30100               # ECP client port

# Deployment mode

-e deployment_mode=remote            # Run in remote mode

```

## Federation Manager Configuration

### Full OOP (Single FM)

- **Namespace**: `federation-manager`

- **Keycloak**: Single instance

- **MongoDB**: Single instance

- **Purpose**: Production single-operator platform

### All-in-One (Dual FM)

- **Primary FM**:

  - Namespace: `federation-manager`

  - Keycloak realm: Primary

  - MongoDB: Primary instance

- **Remote FM**:

  - Namespace: `federation-manager-remote`

  - Keycloak realm: Secondary

  - MongoDB: Secondary instance

  - Different NodePorts to avoid conflicts

- **Purpose**: Simulate federation for testing

### Dual OOP (Real Federation)

- **OP1**: Single FM on first host

- **OP2**: Single FM on second host

- **Purpose**: Real production federation across hosts

## Troubleshooting

### Playbook Not Found

If you see `ERROR! the playbook: ... could not be found`:

- Ensure you're running from the `ansible/` directory

- Check the path is correct (now includes subdirectories)

### Variables Not Loading

If variables seem missing:

- Group variables auto-load from `group_vars/all/`

- Ensure `secrets.yml` is passed with `-e @secrets.yml`

- Check `ansible.cfg` points to correct `inventory/` and `group_vars/`

### Kind Cluster Already Exists

If Kind cluster already exists and you want to recreate:

```bash

ansible-playbook ... -e recreate_cluster=yes

```

### Port Conflicts (All-in-One Scenario)

The all_in_one scenario handles port conflicts automatically by using different NodePorts for the remote FM. If you encounter conflicts, check the variables in `group_vars/all/federation_manager.yml`.

### Federation Manager Not Connecting

For all_in_one scenario, ensure both FMs can reach lite2edge on the shared NodePort. Check:

```bash

kubectl get svc -n lite2edge

kubectl get pods -n federation-manager

kubectl get pods -n federation-manager-remote

```

## Migration Notes

This directory was reorganized to reflect three distinct use cases:

| Old Path | New Path | Notes |

|----------|----------|-------|

| `single_full_oop/` | `all_in_one/` | Renamed to clarify dual FM purpose |

| N/A | `full_oop/` | **NEW** - single FM production scenario |

| `dual_oop/` | `dual_oop/` | Unchanged |

| `deploy_oop_with_oeg_srm.yml` | *Removed* | Duplicate |

| `undeploy_oop_with_oeg_srm.yml` | *Removed* | Duplicate |

**Key Differences:**

- **`full_oop/`**: Does NOT deploy `federation-manager/deploy-remote.yml`

- **`all_in_one/`**: Deploys both `federation-manager/deploy.yml` AND `federation-manager/deploy-remote.yml`

- **`dual_oop/`**: Each host deploys only `federation-manager/deploy.yml` (not remote)

## Testing Recommendations

### Development Workflow

1. Start with **all_in_one** to test federation features

2. Once working, test with **dual_oop** for real federation

3. For production single-operator, use **full_oop**

### CI/CD Pipeline

- Use **all_in_one** for automated federation testing

- Faster than dual_oop and requires only one host

### Production

- Use **full_oop** for single-operator deployments

- Use **dual_oop** for multi-operator federation

## Contributing

When adding new scenarios:

1. Create a new subdirectory under `scenarios/`

2. Follow the naming convention: `deploy.yml`, `graceful_undeploy.yml`, `quick_undeploy.yml`

3. Update this README with scenario details

4. Ensure relative paths use `../../` to reach parent playbooks

5. Add proper usage examples and variable documentation

6. Include clear use case descriptions

---

*For role-specific documentation, see `ansible/roles/README.md`*  

*For variable documentation, see `ansible/group_vars/README.md`*