tepichord/milner
1
1
Fork 0
Code Issues 10 Pull requests 2 Projects 1 Releases Packages Wiki Activity Actions

Determine incremental deployment methodology #27

New issue
Closed
opened 2026-08-21 18:41:30 -07:00 by tepichord · 9 comments
tepichord commented 2026-08-21 18:41:30 -07:00
Owner
Copy link
  • I was working on pr #22, issue #12 and was encountering problems applying an incremental change to the talos control-plane.
  • The instructions to create the control plane relied upon a clean and fresh environment to work when I already have a partially deployed environment.
  • There was some back and forth with the agent just suggesting I run these specific commands to account for my partial configuration and that would've made it into the repositories actual README.md documentation.
  • my wonder is, I ran the cleanup script, shouldn't the script reset the environment to a known good state?
  • I'd like to discuss methodology for developing incremental changes for this IaC project. How do you believe incremental changes be conceived and applied? In my mind, calling terraform apply should either a) only apply the incremental changes (the delta's so to speak) or b) if a isn't possible, then a way to reset the ephemeral elements should be supplied (excluding persistent storage obviously and other elements) then terraform can be ran as though it's a first time apply again, or c) A method to apply changes that accounts for partial setups should be provided alongside each change that is easy to execute (maybe a script that can be ran similar to how migrations are created for db's)
  • Once we determine the methodology, I'd like to evaluate which aspects of the milner project (based on ARCHITECTURE.md) specific methodologies can be applied for (maybe control plane is incapable of utilizing terraform entirely so methodology b applies, while a specific pod like HC Vault could be created with methodology a).
- I was working on pr #22, issue #12 and was encountering problems applying an incremental change to the talos control-plane. - The instructions to create the control plane relied upon a clean and fresh environment to work when I already have a partially deployed environment. - There was some back and forth with the agent just suggesting I run these specific commands to account for my partial configuration and that would've made it into the repositories actual README.md documentation. - my wonder is, I ran the cleanup script, shouldn't the script reset the environment to a known good state? - I'd like to discuss methodology for developing incremental changes for this IaC project. How do you believe incremental changes be conceived and applied? In my mind, calling terraform apply should either a) only apply the incremental changes (the delta's so to speak) or b) if a isn't possible, then a way to reset the ephemeral elements should be supplied (excluding persistent storage obviously and other elements) then terraform can be ran as though it's a first time apply again, or c) A method to apply changes that accounts for partial setups should be provided alongside each change that is easy to execute (maybe a script that can be ran similar to how migrations are created for db's) - Once we determine the methodology, I'd like to evaluate which aspects of the milner project (based on ARCHITECTURE.md) specific methodologies can be applied for (maybe control plane is incapable of utilizing terraform entirely so methodology b applies, while a specific pod like HC Vault could be created with methodology a).
tepichord added this to the MVP project 2026-08-21 18:41:30 -07:00
tepichord commented 2026-08-21 18:57:21 -07:00
Author
Owner
Copy link

Naina:
Naina:
Updated on 2026-08-22 based on maintainer feedback.

Overview

Define Milner's incremental deployment methodology and commit it to documentation in absolute terms so agents adhere closely. Per maintainer comment #7594, this is strictly a methodology + documentation issue — NO code changes. The strategy: option (a) Terraform delta is the default everywhere past the VM/base-infra boundary, option (b) terraform apply -replace is used only at the VM-level base infrastructure for disposable nodes (keeping the persistent volume/network/pool separate and protected), and option (c) per-change migration scripts are rejected outright. The deliverables are the methodology text and an ARCHITECTURE.md component mapping; all current-environment friction (partial control-plane deployment) is explicitly out of scope.

Technical Approach

  1. Record the layer boundary — which layers have a real in-place delta and what to do per layer.

    Layer Real in-place delta? Default Recovery
    VM, disk, libvirt network/pool No Terraform (a) Replace only the disposable VM (b), protect volume/network/pool
    Talos machine configuration Yes Terraform delta (a) Re-apply/stage the changed config (staged_if_needing_reboot), never reset the node
    Pods / Helm / Compose Yes Reconcile the release/chart (a) Roll back or reconcile, never recreate workers

  2. Document what (a) looks like in practice — one change, apply, only that reconciles.

    # change one value, apply, only that releases/charts reconcile
helm upgrade --install woodpecker . --values values.yaml
podman-compose -f hc-vault/docker-compose.yml up -d   # preserves ./vault_data
terraform plan && terraform apply

  3. Document what (b) looks like in practice — swap only the disposable VM, keep the disk/network/pool.

    terraform plan  -replace='libvirt_domain.control_plane'
terraform apply -replace='libvirt_domain.control_plane'

    Keep the domain and persistent volume as separate resources so the volume is never a replacement target:

    resource "libvirt_volume" "control_plane_disk" {
  lifecycle { prevent_destroy = true }
}

  4. Define cleanup.sh's exact purpose in absolute terms: full cluster teardown only. -replace swaps the disposable node but does not remove the environment (network, pool, kubeconfig/talos contexts); cleanup.sh is the confirmation-gated full removal tool, never a partial-recovery tool (recovery is -replace), and it must never globally pkill QEMU or silently delete state/persistent data. (Documenting the contract; editing the script itself is out of scope.)

  5. Frame adoption paths, not divergent instruction sets. Record the single-graph framing: clean install = apply from empty; incremental adopt/recover = import existing UUID → review plan → apply (same main.tf, different entry points).

  6. Write the methodology in absolute terms in README.md and ARCHITECTURE.md: what (a)/(b) are in practice, best practices for each ((a): plan before apply, confirmation-gated, never commit state/secrets, prefer -replace over destroy+recreate; (b): volume separate with prevent_destroy, review every -replace, never hand-run virsh/qemu-img), the layer boundary table, and the clean-install vs incremental-adopt framing. All commands run inside nix develop.

  7. Map every ARCHITECTURE.md component to (a)/(b).

    Component Normal reconciliation (a) Recovery (b)
    Control plane Terraform domain + Talos resources Replace only the disposable node
    Worker-large / worker-sim Terraform node graph Replace one worker, preserve other nodes/data
    HC Vault Idempotent Compose now; Helm later Reconcile containers, preserve ./vault_data
    Woodpecker Helm values upgrade / rollback No VM reset for pod/release changes

Implementation Details

  • Modify: README.md — add/adjust the "How Changes Ship" section to state the methodology, the layer-boundary table, what (a)/(b) are in practice, cleanup's exact purpose, and best practices in absolute terms.
  • Modify: ARCHITECTURE.md — add the per-component (a)/(b) mapping table and the layer-boundary (VM → Talos config → pods/Helm) framing.
  • Modify (documentation only): control-plane/README.md — note the clean-install vs incremental-adopt pathways and cleanup purpose.
  • No code changes: no control-plane/main.tf edits, no import {} blocks, no .terraform.lock.hcl, no cleanup.sh edits, no plan.tftest.hcl/test changes. Documentation may reference import/-replace adoption but must not assume a provider version the repo is not yet on (repo pins libvirt ~>0.7; domain-UUID import is confirmed on 0.9.6+ — flag the provider-version dependency).
  • Operational constraints: preserve AGENTS.md hard rules (no terraform apply/talosctl without explicit confirmation; no manual virsh/qemu-img lifecycle); no secrets/certs committed; docs are example-forward and absolute in tone.
  • Out-of-scope notes: any current-environment remediation (partially deployed control-plane adoption, import, disk reset), HA control-plane expansion, full worker 1→3 rollout, Vault in-cluster migration, Woodpecker deployment, KEDA, and workload migrations consume this methodology later — none are implemented here.

Acceptance Criteria

  • README.md documents the methodology in absolute terms: (a) default past the VM boundary, (b) -replace only for disposable VM-level base infra, (c) rejected — plus best practices for each.
  • README.md defines cleanup.sh's exact purpose as full cluster teardown only (never partial recovery, never broad pkill/silent data or state deletion), and notes recovery is -replace.
  • README.md records the layer-boundary table (VM/disk/network/pool, Talos config, pods/Helm/Compose) and the clean-install vs incremental-adopt single-graph framing.
  • ARCHITECTURE.md maps every component (control plane, worker-large, worker-sim, HC Vault, Woodpecker) to its normal (a) and recovery (b) method.
  • No source code, Terraform config, tests, or cleanup.sh are modified — this is documentation-only, per comment #7594.

Testing Plan

  • bash -n / markdown checks that any doc-embedded commands are syntactically valid and example-forward.
  • python -m pytest tests/ -v inside nix develop to confirm no doc change breaks existing lints.
  • Manual review: verify README.md and ARCHITECTURE.md state the methodology in absolute terms and the (a)/(b)/(c) decision and per-component table match this comment.
  • Manual diff review: confirm the diff touches documentation only (no .tf, .sh, .hcl, or test files).

Related Issues

  • Issue #12 — incremental control-plane changes (context for the friction this methodology addresses).
  • PR #22 — source of the partial-deployment friction.
  • Issue #27 — methodology decision (this issue).
Naina: Naina: *Updated on 2026-08-22 based on maintainer feedback.* #### Overview Define Milner's incremental deployment methodology and commit it to documentation in absolute terms so agents adhere closely. Per maintainer comment #7594, this is strictly a methodology + documentation issue — **NO code changes**. The strategy: option (a) Terraform delta is the default everywhere past the VM/base-infra boundary, option (b) `terraform apply -replace` is used only at the VM-level base infrastructure for disposable nodes (keeping the persistent volume/network/pool separate and protected), and option (c) per-change migration scripts are rejected outright. The deliverables are the methodology text and an `ARCHITECTURE.md` component mapping; all current-environment friction (partial control-plane deployment) is explicitly out of scope. #### Technical Approach 1. **Record the layer boundary** — which layers have a real in-place delta and what to do per layer. | Layer | Real in-place delta? | Default | Recovery | |---|---|---|---| | VM, disk, libvirt network/pool | No | Terraform (a) | Replace only the disposable VM (b), protect volume/network/pool | | Talos machine configuration | Yes | Terraform delta (a) | Re-apply/stage the changed config (`staged_if_needing_reboot`), never reset the node | | Pods / Helm / Compose | Yes | Reconcile the release/chart (a) | Roll back or reconcile, never recreate workers | 2. **Document what (a) looks like in practice** — one change, apply, only that reconciles. ```text # change one value, apply, only that releases/charts reconcile helm upgrade --install woodpecker . --values values.yaml podman-compose -f hc-vault/docker-compose.yml up -d # preserves ./vault_data terraform plan && terraform apply ``` 3. **Document what (b) looks like in practice** — swap only the disposable VM, keep the disk/network/pool. ```text terraform plan -replace='libvirt_domain.control_plane' terraform apply -replace='libvirt_domain.control_plane' ``` Keep the domain and persistent volume as separate resources so the volume is never a replacement target: ```hcl resource "libvirt_volume" "control_plane_disk" { lifecycle { prevent_destroy = true } } ``` 4. **Define cleanup.sh's exact purpose in absolute terms: full cluster teardown only.** `-replace` swaps the disposable node but does not remove the environment (network, pool, kubeconfig/talos contexts); `cleanup.sh` is the confirmation-gated *full removal* tool, never a partial-recovery tool (recovery is `-replace`), and it must never globally `pkill` QEMU or silently delete state/persistent data. (Documenting the contract; editing the script itself is out of scope.) 5. **Frame adoption paths, not divergent instruction sets.** Record the single-graph framing: clean install = apply from empty; incremental adopt/recover = import existing UUID → review plan → apply (same `main.tf`, different entry points). 6. **Write the methodology in absolute terms in `README.md` and `ARCHITECTURE.md`**: what (a)/(b) are in practice, best practices for each ((a): plan before apply, confirmation-gated, never commit state/secrets, prefer `-replace` over destroy+recreate; (b): volume separate with `prevent_destroy`, review every `-replace`, never hand-run `virsh`/`qemu-img`), the layer boundary table, and the clean-install vs incremental-adopt framing. All commands run inside `nix develop`. 7. **Map every `ARCHITECTURE.md` component to (a)/(b).** | Component | Normal reconciliation (a) | Recovery (b) | |---|---|---| | Control plane | Terraform domain + Talos resources | Replace only the disposable node | | Worker-large / worker-sim | Terraform node graph | Replace one worker, preserve other nodes/data | | HC Vault | Idempotent Compose now; Helm later | Reconcile containers, preserve `./vault_data` | | Woodpecker | Helm values upgrade / rollback | No VM reset for pod/release changes | #### Implementation Details - **Modify:** `README.md` — add/adjust the "How Changes Ship" section to state the methodology, the layer-boundary table, what (a)/(b) are in practice, cleanup's exact purpose, and best practices in absolute terms. - **Modify:** `ARCHITECTURE.md` — add the per-component (a)/(b) mapping table and the layer-boundary (VM → Talos config → pods/Helm) framing. - **Modify (documentation only):** `control-plane/README.md` — note the clean-install vs incremental-adopt pathways and cleanup purpose. - **No code changes:** no `control-plane/main.tf` edits, no `import {}` blocks, no `.terraform.lock.hcl`, no `cleanup.sh` edits, no `plan.tftest.hcl`/test changes. Documentation may reference `import`/`-replace` adoption but must not assume a provider version the repo is not yet on (repo pins `libvirt ~>0.7`; domain-UUID import is confirmed on 0.9.6+ — flag the provider-version dependency). - **Operational constraints:** preserve AGENTS.md hard rules (no `terraform apply`/`talosctl` without explicit confirmation; no manual `virsh`/`qemu-img` lifecycle); no secrets/certs committed; docs are example-forward and absolute in tone. - **Out-of-scope notes:** any current-environment remediation (partially deployed control-plane adoption, import, disk reset), HA control-plane expansion, full worker 1→3 rollout, Vault in-cluster migration, Woodpecker deployment, KEDA, and workload migrations consume this methodology later — none are implemented here. #### Acceptance Criteria - [ ] `README.md` documents the methodology in absolute terms: (a) default past the VM boundary, (b) `-replace` only for disposable VM-level base infra, (c) rejected — plus best practices for each. - [ ] `README.md` defines cleanup.sh's exact purpose as full cluster teardown only (never partial recovery, never broad `pkill`/silent data or state deletion), and notes recovery is `-replace`. - [ ] `README.md` records the layer-boundary table (VM/disk/network/pool, Talos config, pods/Helm/Compose) and the clean-install vs incremental-adopt single-graph framing. - [ ] `ARCHITECTURE.md` maps every component (control plane, worker-large, worker-sim, HC Vault, Woodpecker) to its normal (a) and recovery (b) method. - [ ] No source code, Terraform config, tests, or `cleanup.sh` are modified — this is documentation-only, per comment #7594. #### Testing Plan - `bash -n` / markdown checks that any doc-embedded commands are syntactically valid and example-forward. - `python -m pytest tests/ -v` inside `nix develop` to confirm no doc change breaks existing lints. - Manual review: verify `README.md` and `ARCHITECTURE.md` state the methodology in absolute terms and the `(a)/(b)/(c)` decision and per-component table match this comment. - Manual diff review: confirm the diff touches documentation only (no `.tf`, `.sh`, `.hcl`, or test files). #### Related Issues - [Issue #12](https://git.gloom.garden/tepichord/milner/issues/12) — incremental control-plane changes (context for the friction this methodology addresses). - [PR #22](https://git.gloom.garden/tepichord/milner/pulls/22) — source of the partial-deployment friction. - [Issue #27](https://git.gloom.garden/tepichord/milner/issues/27) — methodology decision (this issue).
tepichord commented 2026-08-21 19:47:57 -07:00
Author
Owner
Copy link

Planning comment aside, respond to this comment with your thoughts on potential options to take for this methodology. Lay them out and compare each of the options, including where they might apply.

Planning comment aside, respond to this comment with your thoughts on potential options to take for this methodology. Lay them out and compare each of the options, including where they might apply.
tepichord commented 2026-08-21 19:59:45 -07:00
Author
Owner
Copy link

Naina:
I recommend option (a) as the default: Terraform’s reviewed plan/apply already converges partial infrastructure and applies only the declared delta. Use option (b) for disposable boundaries such as a control-plane or worker VM: replace the domain with terraform apply -replace=... while keeping the network, pool, and data volume protected; a full disk reset remains a separate, explicit destructive operation. Use option (c) only for thin, repeatable adoption/recovery sequencing—not as per-change migrations—because scripts otherwise become a second source of truth. That maps to Terraform deltas plus targeted replacement for the control plane and workers, idempotent compose/Helm reconciliation for HC Vault and Woodpecker, and helper scripts only around those workflows.

Naina: I recommend option (a) as the default: Terraform’s reviewed plan/apply already converges partial infrastructure and applies only the declared delta. Use option (b) for disposable boundaries such as a control-plane or worker VM: replace the domain with `terraform apply -replace=...` while keeping the network, pool, and data volume protected; a full disk reset remains a separate, explicit destructive operation. Use option (c) only for thin, repeatable adoption/recovery sequencing—not as per-change migrations—because scripts otherwise become a second source of truth. That maps to Terraform deltas plus targeted replacement for the control plane and workers, idempotent compose/Helm reconciliation for HC Vault and Woodpecker, and helper scripts only around those workflows.
tepichord commented 2026-08-21 20:15:49 -07:00
Author
Owner
Copy link

Okay ignoring the planning comment and looking at your recommendation:

  • What do the options look like in practice? And what are the boundaries defined wherein? I would prefer an example based exchange on the ideas for each option
  • Do the options look different depending on the infrastructural layer (e.g. pods vs worker nodes)
  • Based on what you said, I don't think we should ever do option c, it sounds too cumbersome.
  • Would you agree that option b should only be used for the base infrastructure, the VM level machine setup for the cluster, then past that option a can be used pretty much wholesale?
Okay ignoring the planning comment and looking at your recommendation: - What do the options look like in practice? And what are the boundaries defined wherein? I would prefer an example based exchange on the ideas for each option - Do the options look different depending on the infrastructural layer (e.g. pods vs worker nodes) - Based on what you said, I don't think we should ever do option c, it sounds too cumbersome. - Would you agree that option b should only be used for the base infrastructure, the VM level machine setup for the cluster, then past that option a can be used pretty much wholesale?
tepichord commented 2026-08-21 22:11:09 -07:00
Author
Owner
Copy link

Naina:
Yes, I agree with all of that — you've basically got the right shape. Let me make it concrete per option rather than abstract.

(a) — terraform apply as a delta

This is just how Terraform behaves against stateful resources. Change one thing, apply, and only that changes:

resource "helm_release" "woodpecker" {
  values = [file("woodpecker/values.yaml")]
}

One value changed → only that release is reconciled. Toward pods/releases, this is the whole story.

(b) — replace only the disposable VM

This is where Terraform cannot diff in place. A VM created by virt-install from an ISO isn't a stateful resource, so the only honest "delta" for the VM itself is recreate:

terraform plan  -replace='libvirt_domain.control_plane'
terraform apply -replace='libvirt_domain.control_plane'

Only the domain is replaced; network, pool, and the persistent data volume stay untouched (separate libvirt_volume with prevent_destroy). Past the VM boundary, config is a delta again, not a reset:

talos_machine_configuration_apply.control_plane {
  apply_mode = "staged_if_needing_reboot"   # apply config delta, don't reset the node
}

(c) — per-change migration scripts

Agreed, drop it as a methodology. It becomes a second source of truth you have to keep in sync with reality. An adoption/recovery helper (import an existing VM once) is fine, but not a migration script per change.

Layers:

Layer Real in-place delta? Approach
VM / disk / network / pool No (b) replace the disposable VM, protect the volume
Talos machine config Yes (a) apply config delta, staged mode
Pods / Helm / Compose Yes (a) reconcile the release/chart

So exactly your read: (b) only at the VM-level base infrastructure (and even then only the disposable node, keeping the disk separate), and past that, (a) is used pretty much wholesale.

On cleanup.sh — yes, it should reset to a known-good state, but scoped to what Terraform owns: destroy managed resources + remove the talosctl client context, never globally pkill qemu or delete persistent storage. I'll fold this into the plan revision.

Naina: Yes, I agree with all of that — you've basically got the right shape. Let me make it concrete per option rather than abstract. **(a) — `terraform apply` as a delta** This is just how Terraform behaves against stateful resources. Change one thing, apply, and only that changes: ```hcl resource "helm_release" "woodpecker" { values = [file("woodpecker/values.yaml")] } ``` One value changed → only that release is reconciled. Toward pods/releases, this is the whole story. **(b) — replace only the disposable VM** This is where Terraform *cannot* diff in place. A VM created by `virt-install` from an ISO isn't a stateful resource, so the only honest "delta" for the VM itself is recreate: ```bash terraform plan -replace='libvirt_domain.control_plane' terraform apply -replace='libvirt_domain.control_plane' ``` Only the domain is replaced; network, pool, and the persistent data volume stay untouched (separate `libvirt_volume` with `prevent_destroy`). Past the VM boundary, config is a delta again, not a reset: ```hcl talos_machine_configuration_apply.control_plane { apply_mode = "staged_if_needing_reboot" # apply config delta, don't reset the node } ``` **(c) — per-change migration scripts** Agreed, drop it as a methodology. It becomes a second source of truth you have to keep in sync with reality. An adoption/recovery helper (import an existing VM once) is fine, but not a migration script per change. **Layers:** | Layer | Real in-place delta? | Approach | |---|---|---| | VM / disk / network / pool | No | (b) replace the disposable VM, protect the volume | | Talos machine config | Yes | (a) apply config delta, staged mode | | Pods / Helm / Compose | Yes | (a) reconcile the release/chart | So exactly your read: (b) only at the VM-level base infrastructure (and even then only the disposable node, keeping the disk separate), and past that, (a) is used pretty much wholesale. On `cleanup.sh` — yes, it should reset to a known-good state, but scoped to what Terraform owns: destroy managed resources + remove the talosctl client context, never globally `pkill qemu` or delete persistent storage. I'll fold this into the plan revision.
tepichord commented 2026-08-22 00:46:21 -07:00
Author
Owner
Copy link
  • So with approach (b) possible via terraform -replace, do we even need a cleanup script?
  • Also, how do you suppose that strategies for (b) be defined and ran? Is it just a documentation section in a README.md? Does there need to be two sets of instructions, one for clean install vs. incremental changes?
- So with approach (b) possible via terraform -replace, do we even need a cleanup script? - Also, how do you suppose that strategies for (b) be defined and ran? Is it just a documentation section in a README.md? Does there need to be two sets of instructions, one for clean install vs. incremental changes?
tepichord commented 2026-08-22 01:11:53 -07:00
Author
Owner
Copy link

Naina:
Yes, a cleanup script still earns its keep — terraform apply -replace only swaps the disposable VM; it doesn't tear down the whole control-plane environment (network, pool, kubeconfig/talos contexts). When you want to fully remove a cluster you'd otherwise hand-run terraform destroy plus talosctl config remove plus kubeconfig cleanup, so cleanup.sh stays — but rebased to Terraform ownership: validate target → show exact disposable targets → confirmation-gated terraform destroy → talosctl config remove. No global pkill qemu, no silent state or persistent-data deletion.

For how (b) gets defined and run: it's a README documentation section with the concrete command — terraform plan -replace='libvirt_domain.control_plane' to recover the disposable node while the volume stays protected. And yes, there are effectively two pathway docs (clean-install bootstrap vs incremental adopt/recover), but they share ONE Terraform graph, not two divergent instruction sets: the clean path is an apply from empty, the incremental path is import existing UUID → review plan → apply. Same main.tf, different entry points.

Naina: Yes, a cleanup script still earns its keep — `terraform apply -replace` only swaps the disposable VM; it doesn't tear down the whole control-plane environment (network, pool, kubeconfig/talos contexts). When you want to fully remove a cluster you'd otherwise hand-run `terraform destroy` plus `talosctl config remove` plus kubeconfig cleanup, so cleanup.sh stays — but rebased to Terraform ownership: validate target → show exact disposable targets → confirmation-gated `terraform destroy` → `talosctl config remove`. No global `pkill qemu`, no silent state or persistent-data deletion. For how (b) gets defined and run: it's a README documentation section with the concrete command — `terraform plan -replace='libvirt_domain.control_plane'` to recover the disposable node while the volume stays protected. And yes, there are effectively two pathway docs (clean-install bootstrap vs incremental adopt/recover), but they share ONE Terraform graph, not two divergent instruction sets: the clean path is an apply from empty, the incremental path is import existing UUID → review plan → apply. Same `main.tf`, different entry points.
tepichord commented 2026-08-22 01:24:22 -07:00
Author
Owner
Copy link
  • Alright update the plan to write documentation that solidifies everything we've discussed here in absolute terms so that it's adhered to closely by agents.
  • The exact purpose of cleanup scripts
  • What methodologies a, and b are and what they look like in practice
  • Best practices to implement for a or b
  • Also indicate which method different elements of the architecture adhere to via the ARCHITECTURE.md file.
- Alright update the plan to write documentation that solidifies everything we've discussed here in absolute terms so that it's adhered to closely by agents. - The exact purpose of cleanup scripts - What methodologies a, and b are and what they look like in practice - Best practices to implement for a or b - Also indicate which method different elements of the architecture adhere to via the ARCHITECTURE.md file.
tepichord commented 2026-08-22 01:57:49 -07:00
Author
Owner
Copy link

The control-plane implementation must first move VM ownership from null_resource/virt-install into a stateful Terraform graph so a partially deployed environment can be adopted and reconciled without touching persistent storage, and the methodology must be committed to documentation in absolute terms so agents follow it closely.

This is purely out of scope for this issue, this issue is simply a methodology and document issue. NO code changes will be done. I would like to define a strategy to best ensure success in the future, not concerned with the current issues at play that conflict with the strategy. Update the planning comment to reflect that.

> The control-plane implementation must first move VM ownership from null_resource/virt-install into a stateful Terraform graph so a partially deployed environment can be adopted and reconciled without touching persistent storage, and the methodology must be committed to documentation in absolute terms so agents follow it closely. This is purely out of scope for this issue, this issue is simply a methodology and document issue. NO code changes will be done. I would like to define a strategy to best ensure success in the future, not concerned with the current issues at play that conflict with the strategy. Update the planning comment to reflect that.
tepichord 2026-08-22 04:07:01 -07:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feat/12-iac-control-plane
feat/3-setting-up-agent-development
kvm-kubernetes-setup
No results found.
Labels
Clear labels   
bug

Something is not working

  
duplicate

This issue or pull request already exists

  
effort
high

  
effort
low

  
effort
medium

  
effort
minimal

  
enhancement

New feature

  
help wanted

Need some help

  
invalid

Something is wrong

  
pr
feedback
Used for PRs, indicates that feedback has been given and agent needs to make changes

  
pr
reviewing
Used for PRs, indicates that a human is waiting to review the pull request, no action needed by the agent

  
question

More information is needed

  
status
backlog
Ignore, no work needed yet, human will assign this work by changing to status/planning

  
status
document
Record findings, create flashcards, and document knowledge in knowledgebase for the future

  
status
done
Completed when PR is merged, no more work needed.

  
status
implement
Make the code changes. Should be done by a faster and cheaper model

  
status
pending
Give human a chance to review planning details

  
status
planning
Ready to begin. Fill out implementation details and things like acceptance criteria, etc. A smarter thoughtful llm should be delegated for this

  
status
reviewing
PR is created and feedback loop begins between human and agent

  
wontfix

This won't be fixed

No labels
bug
duplicate
effort
high
effort
low
effort
medium
effort
minimal
enhancement
help wanted
invalid
pr
feedback
pr
reviewing
question
status
backlog
status
document
status
done
status
implement
status
pending
status
planning
status
reviewing
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
MVP
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
tepichord/milner#27
No description provided.