VM-Based Delivery for Omnia-Controlled Non-OIM Functional Groups

The issue names no source files, tests or entry points, so there is no code to start from. It is a product specification whose acceptance criteria (AC-001 to AC-009) cover a guest artifact, a compatibility profile and a Service Kubernetes control-plane group. A newcomer should first read the Open Questions section and ask the maintainers which part is in scope for a first contribution.

VM-Based Delivery for Omnia-Controlled Non-OIM Functional Groups

---

Summary

Infrastructure Administrators need Omnia-controlled functional groups to run on externally instantiated virtual machines without making a production hypervisor part of Omnia's responsibility. Omnia supplies a portable guest artifact and approved compatibility profile, then configures reachable guests. The Service Kubernetes control-plane group is the first qualified group.

---

Problem Statement

Omnia-controlled functional groups have historically assumed bare-metal provisioning or provider-specific VM lifecycle automation. That coupling mixes guest configuration with responsibilities that belong to the external virtualization owner and creates unnecessary dependencies on provider APIs.

The product needs a bounded guest-delivery boundary that can be demonstrated on compatible KVM/libvirt and Proxmox environments without claiming universal portability or making either provider a production dependency. Omnia must not become responsible for lifecycle management of externally owned appliances.

---

Value Proposition

Customer Value

Customers can instantiate an approved guest artifact on compatible virtualization and hand reachable VMs to Omnia for functional-group configuration. They retain control of VM creation, runtime, storage, networking, placement, restart, and HA while receiving a documented compatibility profile and clear guest-readiness diagnostics.

---

User Personas

• Infrastructure Administrator: Owns the external virtualization environment and creates guests from the approved artifact.
• Omnia Cluster Administrator: Supplies guest connection and functional-group inputs and needs deterministic configuration and readiness evidence.
• Product Validation Engineer: Qualifies guest artifacts and compatibility profiles across supported lab providers.

---

Use Cases

Use Case 1: Instantiate a Compatible Guest

Actor: Infrastructure Administrator
Context: An approved guest artifact and compatibility profile are available.
Action: The administrator creates a VM using provider-owned tools and establishes supported reachability.
Result: Omnia can validate the guest without provider API access.

Use Case 2: Configure the Service Kubernetes Control-Plane Group

Actor: Omnia Cluster Administrator
Context: Reachable guests satisfy the approved profile.
Action: Omnia configures them as Service Kubernetes control-plane nodes.
Result: The group reaches its application-readiness outcome; Slurm services remain governed by JA-6312.

Use Case 3: Demonstrate Guest Portability

Actor: Product Validation Engineer
Context: A release candidate artifact/profile is ready.
Action: The same profile is demonstrated on KVM/libvirt and, when compatible, Proxmox using provider-owned VM instantiation.
Result: Guest delivery is validated without a production dependency on either provider or its APIs.

---

Scope Definition

Goals

• Supply a portable guest artifact and versioned compatibility profile.
• Qualify the Service Kubernetes control-plane group first.
• Configure guests only after external instantiation and reachability.
• Avoid required Proxmox, KVM, or libvirt API integration.
• Demonstrate the approved profile on KVM/libvirt and conditionally on Proxmox.
• Require explicit qualification before supporting another non-OIM functional group.

Non-Goals

• OIM delivery or lifecycle, which remains governed by OIM-specific specifications.
• OME/Polaris, SFM, UFM, or other non-Omnia appliance lifecycle.
• VM creation, runtime, storage, networking, placement, restart, migration, backup, restore, fencing, or HA.
• Production provider API integration or credentials.
• Universal VM portability across unqualified firmware, machine types, controllers, CPU models, architectures, datasources, or guest agents.
• Additional functional groups without explicit qualification.
• Redefining application behavior owned by JA-6312 or another application specification.

---

Requirements

Requirement 1: Portable Guest Artifact and Profile [Req 1]

Omnia must release a guest artifact with a versioned compatibility profile covering OS, architecture, firmware mode, machine type, disk/NIC controllers, CPU flags, cloud-init datasource, and guest-agent expectations.

Scenario: Profile-compatible guest

• A guest matching the profile proceeds to reachability and functional-group validation.

Scenario: Profile mismatch

• Unsupported settings stop before Omnia configuration and identify the incompatible field.

Requirement 2: Provider-Owned Instantiation and Reachability [Req 2]

The external virtualization owner must create and operate the VM and establish supported guest reachability before Omnia configuration begins.

Scenario: Reachable guest

• Omnia authenticates to the guest through the supported guest interface without provider API access.

Scenario: Guest unreachable

• Configuration stops with an ownership-specific diagnostic and does not attempt a provider lifecycle action.

Requirement 3: Service Kubernetes Guest Configuration [Req 3]

Omnia must configure approved guests as the Service Kubernetes control-plane functional group and report group readiness.

Scenario: Configuration succeeds

• Compatible reachable guests receive Omnia-owned configuration and pass membership and readiness checks.

Scenario: Application readiness fails

• Omnia reports guest configuration separately from Service Kubernetes readiness and does not trigger VM restart or replacement.

Requirement 4: Explicit Functional-Group Qualification [Req 4]

Only the Service Kubernetes control-plane group is initially qualified; additional groups require a separate qualification record.

Scenario: Qualified group requested

• The initial group is accepted when the guest and inputs satisfy its record.

Scenario: Unqualified group requested

• Another group is rejected until product approval and qualification evidence exist.

Requirement 5: Provider-Neutral Acceptance [Req 5]

The supported deployment boundary must operate without provider APIs and record KVM/libvirt and conditional Proxmox demonstrations.

Scenario: Compatible demonstrations

• Demonstrations use the approved qcow2 or raw artifact plus cloud-init NoCloud-style guest data without provider-specific devices embedded in the artifact.

Scenario: Provider incompatibility

• If Proxmox cannot satisfy the profile without provider-specific artifact changes, the result is recorded as unsupported rather than weakening the profile.

Requirement 6: Excluded-System Boundary [Req 6]

Omnia must not instantiate or lifecycle-manage OIM or non-Omnia appliances under this capability.

Scenario: External appliance requested

• Requests for OME/Polaris, SFM, UFM, or another external appliance are routed to the appliance and virtualization owners.

Scenario: VM lifecycle action requested

• Start, stop, restart, placement, migration, backup, restore, fencing, and HA requests remain outside the supported workflow.

---

Reliability

Failure Mode	System Behavior
Artifact unavailable or invalid	Delivery stops before guest handoff.
Guest profile mismatch	Configuration is blocked and the incompatible profile field is reported.
Guest unreachable	Omnia reports guest reachability separately and does not call provider APIs.
Guest configured but application unhealthy	Guest configuration and application readiness remain distinct states.
Provider runtime failure	Escalation points to the external virtualization owner.

Recovery: Omnia resumes validation and configuration after the provider restores a reachable profile-compatible guest.

---

Security

• Artifacts include provenance, integrity, entitlement, and vulnerability evidence.
• Guest authentication follows approved key or credential handling.
• No provider credentials are required by the initial product workflow.
• Compatibility validation rejects unsafe firmware, controller, datasource, or guest-agent assumptions.
• Non-Omnia appliance ownership is not represented as an Omnia security control.

---

Telemetry

Omnia records guest-profile validation, reachability, configuration progress, readiness, and failure ownership. Provider utilization, placement, restart, storage, network, and HA telemetry remain provider-owned.

---

Documentation

• Guest artifact and compatibility-profile reference.
• External VM instantiation and reachability handoff guide.
• Service Kubernetes guest configuration and readiness guide.
• Troubleshooting guide separating profile, reachability, configuration, application, and provider failures.
• Release qualification records for KVM/libvirt and conditional Proxmox compatibility.

---

Dependencies

• External virtualization environment capable of instantiating the approved guest profile.
• Versioned guest artifact with release provenance and integrity evidence.
• Supported guest reachability and authentication.
• Service Kubernetes qualification requirements.
• JA-6312 for Slurm services deployed on Service Kubernetes.
• JA-14405 for OIM VM/application-HA ownership.

---

Risks

Risk	Category	Impact	Likelihood	Mitigation
Artifact assumed universally portable	Technical	High	Medium	Publish and enforce the exact compatibility profile.
Provider lifecycle ownership leaks into Omnia	Scope	High	Medium	Require a reachable-guest handoff and no provider credentials.
Unqualified functional group is treated as supported	Product	High	Medium	Require explicit qualification records.
External appliance is mistaken for Omnia scope	Operational	High	Medium	Exclude OME/Polaris, SFM, UFM, and OIM in workflow and documentation.
Guest is healthy but application is not	Operational	High	Medium	Report guest configuration and application readiness separately.

---

Acceptance Criteria

• AC-001: The release publishes a guest artifact and complete versioned compatibility profile. [Req 1]
• AC-002: A compatible reachable guest is validated and configured without provider API access. [Req 1] [Req 2]
• AC-003: Service Kubernetes control-plane guests pass group membership and readiness checks. [Req 3]
• AC-004: Application failure is reported without triggering a provider lifecycle action. [Req 3]
• AC-005: Profile mismatch and guest unreachability stop before configuration with ownership-specific diagnostics. [Req 1] [Req 2]
• AC-006: The initial workflow accepts Service Kubernetes and rejects an unqualified additional group. [Req 4]
• AC-007: OME/Polaris, SFM, UFM, OIM, and VM lifecycle actions are absent from the supported workflow. [Req 6]
• AC-008: The same approved profile is demonstrated on KVM/libvirt and on Proxmox when compatible. [Req 5]
• AC-009: The Service Kubernetes record states that Slurm application ownership remains in JA-6312. [Req 3] [Req 4]

---

Scope & Sequencing

• Initial scope: Portable guest artifact/profile and Service Kubernetes control-plane guest configuration.
• Acceptance: Required KVM/libvirt demonstration and conditional Proxmox demonstration.
• Later qualification: Additional Omnia-controlled non-OIM groups require separate approval and evidence.
• Future provider work: Provider APIs, automated VM creation, placement, restart, migration, backup, restore, fencing, and HA.

---

Assumptions / Open Questions

Assumptions

• A provider-neutral qcow2 or raw artifact with cloud-init NoCloud-style data can satisfy the approved profile.
• Virtualization owners can map the profile and establish guest reachability.
• KVM/libvirt is available for required lab acceptance; Proxmox is available when compatible.

Open Questions

• What exact OS, architecture, firmware, machine type, controller, CPU, datasource, and guest-agent profile is approved?
• Which disk artifact formats and release evidence are required?
• Does the approved profile satisfy Proxmox without provider-specific artifact changes?
• What record and approvers are required for later functional groups?

---