Conversation
OpenTofu TestOpenTofu test passed. View run output |
OpenTofu PlanOpenTofu plan passed. View run outputOpenTofu will perform the following actions:
# module.k3s.libvirt_cloudinit_disk.commoninit will be created
+ resource "libvirt_cloudinit_disk" "commoninit" {
+ id = (known after apply)
+ meta_data = <<-EOT
instance-id: k3s
local-hostname: k3s
EOT
+ name = "k3s_commoninit"
+ network_config = <<-EOT
version: 2
ethernets:
enp1s0:
dhcp4: true
enp2s0:
dhcp4: false
addresses:
- 192.168.102.2/24
EOT
+ path = (known after apply)
+ size = (known after apply)
+ user_data = (sensitive value)
}
# module.runner.libvirt_cloudinit_disk.commoninit will be created
+ resource "libvirt_cloudinit_disk" "commoninit" {
+ id = (known after apply)
+ meta_data = <<-EOT
instance-id: runner
local-hostname: runner
EOT
+ name = "runner_commoninit"
+ network_config = (sensitive value)
+ path = (known after apply)
+ size = (known after apply)
+ user_data = (sensitive value)
}
Plan: 2 to add, 0 to change, 0 to destroy.
OpenTofu will perform the following actions:
# module.k3s.libvirt_cloudinit_disk.commoninit will be created
+ resource "libvirt_cloudinit_disk" "commoninit" {
+ id = (known after apply)
+ meta_data = <<-EOT
instance-id: k3s
local-hostname: k3s
EOT
+ name = "k3s_commoninit"
+ network_config = <<-EOT
version: 2
ethernets:
enp1s0:
dhcp4: true
enp2s0:
dhcp4: false
addresses:
- 192.168.102.2/24
EOT
+ path = (known after apply)
+ size = (known after apply)
+ user_data = (sensitive value)
}
# module.runner.libvirt_cloudinit_disk.commoninit will be created
+ resource "libvirt_cloudinit_disk" "commoninit" {
+ id = (known after apply)
+ meta_data = <<-EOT
instance-id: runner
local-hostname: runner
EOT
+ name = "runner_commoninit"
+ network_config = (sensitive value)
+ path = (known after apply)
+ size = (known after apply)
+ user_data = (sensitive value)
}
Plan: 2 to add, 0 to change, 0 to destroy. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Documents the confirmation-gated recovery path for the already-authored k3s boot-disk capacity reconciliation. The runbook distinguishes the replace-only boot volume/domain path from the persistent
vdbK3s-data volume, records the expected loss of the in-clusterarc-tfapply runner, and requires a fresh plan before any re-drive.Fixes #
N/A — operational recovery documentation for the recurring root-filesystem capacity alert.
Type of change
Validation
README.mdis generated and unchanged.Review evidence before PR creation:
k3s:vdais 5 GiB andvdbis 400 GiB.main.tfalready requests a 20 GiB k3s boot disk; the prior capacity PR was #23.Impact and rollout
Blocker — do not merge: the authoritative PR plan creates only the two cloud-init disks; it proposes no boot-volume, domain, or
vdbaction. This conflicts with live libvirt evidence thatk3s:vdaremains 5 GiB while desired configuration/state is 20 GiB. The current provider/state path does not surface the required boot-disk reconciliation, so merging this documentation PR cannot fix the alert.The next corrective design must safely reconcile the real 5 GiB libvirt volume with the OpenTofu state before a replacement plan can be trusted. It must preserve the 400 GiB
vdbvolume and account for self-interruption of the in-cluster apply runner.Delivery stages: documentation authored and validated; no desired-state reconciliation, artifact publication, GitOps selection, Argo reconciliation, infrastructure apply, or functional verification has occurred.
Safety and secrets
AI-assisted change; review the full runbook and the credentialed PR plan before considering any merge or production approval.