# Phase 2: Core VM Lifecycle - Discussion Log

> **Audit trail only.** Do not use as input to planning, research, or execution agents.
> Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.

**Date:** 2026-03-22
**Phase:** 02-core-vm-lifecycle
**Areas discussed:** Network lifecycle, Partial failure semantics, Domain XML generation, Overlay disk creation

---

## Network Lifecycle

| Option | Description | Selected |
|--------|-------------|----------|
| Fully managed | cluster_define creates the network, cluster_destroy removes it. Zero manual setup. | ✓ |
| Pre-provisioned | Network must exist before cluster_define. Simpler code, but agents can't self-provision. | |
| Managed with override | Creates by default, but skips if a matching network already exists. Best of both. | |

**User's choice:** Fully managed
**Notes:** Recommended option. Agents need zero manual network pre-provisioning.

---

## Static IP Assignment

| Option | Description | Selected |
|--------|-------------|----------|
| Baked in base image | Base image already has static IP config per node. Simplest but ties image to topology. | |
| cloud-init / NoCloud | Attach a cloud-init ISO with network config per node at define time. Flexible, base image stays generic. | ✓ |
| SSH post-boot | Boot with DHCP, then SSH in to set static IPs. Requires DHCP enabled temporarily. | |
| You decide | Agent discretion — researcher figures out the best approach. | |

**User's choice:** cloud-init / NoCloud
**Notes:** Keeps base images generic and reusable across topologies.

---

## SSH Wait Failure Mode

| Option | Description | Selected |
|--------|-------------|----------|
| Strict (all-or-nothing) | All nodes must be reachable. 2/3 up = success=False. Agent sees the failure and decides. | ✓ |
| Partial success reported | Return success=True with per-node status. Agent checks which nodes failed. More flexible but ambiguous. | |
| You decide | Let the researcher/planner decide based on what works with the error contract. | |

**User's choice:** Strict (all-or-nothing)
**Notes:** Consistent with existing `require_all=True` default on `node_exec_all`.

---

## Define Failure Handling

| Option | Description | Selected |
|--------|-------------|----------|
| Leave partial + report | Leave partial state. Return error with details of what was created. Agent can retry or destroy. | ✓ |
| Rollback on failure | Clean up any domains/overlays created so far. Atomic: either all defined or nothing. | |
| You decide | Let the researcher/planner decide. | |

**User's choice:** Leave partial + report
**Notes:** Simpler implementation. Agent has full control over cleanup via cluster_destroy.

---

## Domain XML Generation

| Option | Description | Selected |
|--------|-------------|----------|
| xml.etree.ElementTree | Build XML tree programmatically with stdlib. No extra dependency. Testable via tree assertions. | ✓ |
| Jinja2 templates | Render from .xml.j2 templates. More readable for complex XML. Adds jinja2 dependency. | |
| String templates | Python f-strings / string concat. Simplest but fragile and hard to test. | |
| You decide | Let the researcher/planner choose. | |

**User's choice:** xml.etree.ElementTree
**Notes:** Stdlib only, no new dependency. Consistent with minimal dependency approach.

---

## Overlay Disk Creation

| Option | Description | Selected |
|--------|-------------|----------|
| subprocess qemu-img | Shell out to qemu-img create. Direct, well-documented, no API complexity. | ✓ |
| libvirt storage pool API | Use libvirt storage pool/volume APIs. More 'proper' but significantly more complex. | |
| You decide | Let the researcher/planner decide based on what suits the threading model. | |

**User's choice:** subprocess qemu-img
**Notes:** Direct approach, avoids storage pool setup complexity.

---

## Destroy Cleanup Scope

| Option | Description | Selected |
|--------|-------------|----------|
| Overlays only | Only remove overlays. Network managed separately. | ✓ |
| Overlays + network | Remove overlays + undefine the libvirt network. | |
| You decide | Let the researcher/planner decide. | |

**User's choice:** Overlays only (for remove_overlays flag)
**Notes:** Clarified that cluster_destroy always removes the network; remove_overlays only controls disk files.

---

## Network Destroy Clarification

| Option | Description | Selected |
|--------|-------------|----------|
| Always remove network | cluster_destroy always removes the network it created. remove_overlays only controls disk files. | ✓ |
| Separate flag | Add a separate remove_network parameter to cluster_destroy. | |
| You decide | Let the researcher/planner decide. | |

**User's choice:** Always remove network
**Notes:** Network lifecycle is fully tied to cluster lifecycle. No separate flag needed.

---

## Agent's Discretion

- Domain XML structure details (specific elements, attributes)
- cloud-init ISO generation specifics (genisoimage vs mkisofs, meta-data format)
- Idempotency check mechanism for cluster_define (CLUS-07)

## Deferred Ideas

None — discussion stayed within phase scope.
