Design Review: Standalone Domain Repository Pattern for Omnia

## Summary

Completed initial design and refactoring of `image_build_manager` into a standalone, independent repository. Requesting design review before applying this pattern to remaining Omnia domains.

**Reference Repository:** https://github.com/abhishek-sa1/image-build-manager
**Documentation:** https://github.com/abhishek-sa1/image-build-manager/blob/main/docs/README.md

---

## Design Documents

Two primary design documents define the new architecture:

1. **[Generic Omnia Domain Repository Standard](https://github.com/abhishek-sa1/image-build-manager/blob/main/docs/design/omnia-domain-repo-design.md)**
- Standard repository layout (`src/`, `docs/`, `test/`)
- `config.yml` structure and host validation rules
- Entry point playbook rules (role/playbook imports only, no inline tasks)
- Role structure and naming conventions (split task files, vars-only error messages)
- Path conventions (`/output//`, `/log//`, etc.)
- Input/output YAML contract patterns between domains
- Ansible, Python, and Jinja2 style guidelines
- Validated environment: Python 3.12+, Ansible Core 2.20+, RHEL 10.0+, Podman 5.0+

2. **[Mode A (Bare-Metal) Execution](https://github.com/abhishek-sa1/image-build-manager/blob/main/docs/design/standalone-mode-a.md)**
- Recommended execution mode for all domains
- Rationale for not supporting container-based modes (Mode B/C)

---

## Key Design Decisions

### 1. Mode A (Bare-Metal) — Recommended Execution Mode

**Recommendation:** Mode A (bare-metal) as the **only** supported execution mode.

**Rationale for not supporting Mode B (per-domain container) and Mode C (Omnia core container):**

| Issue | Impact |
|-------|--------|
| **Host/container path sharing** | Bind-mount path translation between host and container is fragile and error-prone |
| **Privilege escalation complexity** | Containers need `--privileged` or complex UID mapping to manage host services (systemd, Podman, firewall) |
| **Version coupling** | A shared `omnia_core` container creates dependency conflicts between domains |
| **Debugging overhead** | Logs, processes, and filesystem are harder to access inside containers |
| **Air-gap complexity** | Container image distribution adds friction in disconnected environments |

**Status:** Mode B/C code is commented out in the codebase (not deleted) for future reference.

### 2. Vision: No More Core Container

**Proposal:** Eliminate the `omnia_core` container environment entirely.

```
┌──────────────────────────────────────────────────────────────────────┐
│ dell/omnia Architecture │
└──────────────────────────────────────────────────────────────────────┘

User runs: ./omnia.sh
│
├─> Creates Python venv
├─> Installs Ansible + dependencies
└─> Executes domain playbooks:
│
├─> repo_manager/repo_manager.yml
│ (Sync RPM repos via Pulp)
│
├─> image_build_manager/image_build_manager.yml
│ (Build OS images)
│
├─> discovery/discovery.yml
│ (Hardware discovery & inventory)
│
├─> orchestrator/orchestrator.yml
│ (Cluster setup & Day 2 operations)
│
└─> telemetry/telemetry.yml
(Monitoring & observability)

Each domain = standalone git repo following the same design standard
```

**Key Domains:**

repo_manager — RPM repository synchronization via Pulp
image_build_manager — OS image building (bare-metal + containers)
orchestrator — Cluster orchestration, Day 2 operations, lifecycle management
discovery — Hardware discovery and inventory management
telemetry — Monitoring, metrics, and observability

**Benefits:**

- ✅ **Independent domain lifecycles** — each domain versioned, tested, and released independently
- ✅ **Simpler host integration** — all paths, services, and processes are host-native
- ✅ **Easier debugging and development** — no container abstraction layer
- ✅ **Better air-gap support** — virtual environment pattern works in disconnected environments
- ✅ **No container runtime needed** for orchestrator (Podman only used by domains that build/run containers)

---

## What's in the Repository

| Area | Details |
|------|---------|
| **Code** | Fully refactored — all `oim` references removed, split task files, host validation, fail-fast prereq checks |
| **Paths** | `/s3/`, `/registry/`, `/workdir/`, `/output//`, `/log//` |
| **Documentation** | Design docs, code-style guides (Ansible, Python, Jinja2, general), input/output contracts, architecture, troubleshooting |
| **Domain coding rules** | `CODING_RULES.md` — domain-specific rules extending the generic standard |

---

## Validation Completed

The following validation has been completed as part of the refactoring effort:

- [x] Repository successfully refactored into standalone structure
- [x] All legacy `oim` references removed
- [x] Host validation and fail-fast prerequisite checks verified
- [x] Entry-point playbook structure validated
- [x] Role/task decomposition completed and exercised
- [x] Standardized path generation and configuration handling validated
- [x] Documentation, coding standards, and repository structure aligned with implemented design
- [x] Basic standalone execution flow tested in development environment
- [x] All playbook tags validated (`prepare`, `build`, `cleanup`, `validate`)

---

## Request for Feedback

### Primary Questions

1. **Design Standard Approval**
Please review [`docs/design/omnia-domain-repo-design.md`](https://github.com/abhishek-sa1/image-build-manager/blob/main/docs/design/omnia-domain-repo-design.md) — this will be the template for splitting all other domains.

2. **Mode A Recommendation**
Do you agree with the Mode A (bare-metal) recommendation and the rationale for not supporting container-based execution (Mode B/C)?

3. **No-Core-Container Vision**
Feedback on eliminating `omnia_core` container and moving to a lightweight orchestrator + standalone domain repos architecture?

4. **Rollout Plan**
Alignment on applying this pattern to `repo_manager` and `orchestrator` next?

---

## Next Steps

- [ ] Design review and feedback incorporation
- [ ] End-to-end validation on test host
- [ ] Apply same design pattern to `repo_manager` (next candidate)
- [ ] Test automation
- [ ] CI/CD pipeline tuning
- [ ] Documentation finalization

---

## Additional Context

- **Target OS:** RHEL 10.0+ (current validation), Ubuntu support planned
- **Ansible Version:** ansible-core 2.20+
- **Python Version:** 3.12+
- **Container Runtime:** Podman 5.0+ (for domains that need containers like MinIO, Registry)
- **Air-gap Support:** First-class constraint — all designs account for disconnected environments