Skip to content

Add stuck pod describe - #1208

Open
RaunakJalan wants to merge 15 commits into
mainfrom
add-stuck-pod-describe
Open

Add stuck pod describe#1208
RaunakJalan wants to merge 15 commits into
mainfrom
add-stuck-pod-describe

Conversation

@RaunakJalan

Copy link
Copy Markdown
Collaborator

No description provided.

RaunakJalan and others added 15 commits August 1, 2026 21:07
When FIO pods are stuck in PodInitializing or time out during
wait_fio, save kubectl describe output to stuck_pod_describes/
directory for post-mortem debugging of volume mount or CSI failures.
TestSingleNodeOutage: The checksum utility pod was deleted with
--wait=false, causing a name collision when re-created 24s later.
The stale pod returned empty checksums, failing the assertion.
Fix: delete_pod() now accepts wait=True; _generate_checksums_dual
uses it to block until the pod is fully removed.

TestSingleNodeFailure: Stale VolumeSnapshots (snapshot-1, snapshot-2)
from TestSingleNodeOutage persisted because cleanup used --wait=false
and cleanup_k8s_leftovers only matched snap-* prefix. The next test's
kubectl apply hit "persistentVolumeClaimName is immutable", silently
reusing the stale snapshot that pointed to a deleted backend object.

Fixes:
- delete_pod/delete_volume_snapshot: add wait parameter
- _generate_checksums_dual: wait for pod deletion
- Teardown: wait for snapshot deletion + catch-all for untracked snapshots
- cleanup_k8s_leftovers: match snapshot-* in addition to snap-*
- create_volume_snapshot: detect and remove stale snapshot before apply
- Create audit pool in Phase 0 before read-only audits so pool.get,
  pool.iostats, volume.crud, and snapshot.crud are no longer skipped
  with "no pools available"
- Change all not_tested and interface_error severity from WARNING/INFO
  to ERROR — if an interface fails, it should fail the test
- Capture full API call details in every finding: the CLI command or
  HTTP method+path, HTTP status code, and response preview
- _run_cli now returns a dict with data, stdout, stderr, and command
  so failures include the actual stderr output for debugging
- Count mismatches now include sample IDs from each interface so
  it's clear which items are present vs missing
- Report HTML updated with new columns: API Call, HTTP Status,
  Response preview, and sample IDs for count mismatches
- pool.crud uses a separate pool name (parity_crud_pool) so it
  doesn't conflict with the audit pool lifecycle
Full end-to-end runbook covering Phase 1 (R25.x legacy Helm deployment),
Phase 2 (pre-upgrade data setup with FIO/MD5/snapshots/clones), Phase 3
(10-step maintenance window migration), and Phase 4 (post-upgrade
validation including old data verify, new provisioning, and outage tests).
- TC-BCK-018: wait for backup completion before PVC deletion (K8s
  operator re-resolves PVC during reconciliation, causing
  BackupSourceResolutionError when PVC is deleted mid-backup)
- TC-BCK-172: pass restore_size="10G" for resized lvol restore (PVC
  size must match backup size)
- TC-BCK-175: remove -d debug flag that caused false positive error
  assertion on stderr
- Move topology backup tests (TestBackupAfterNodeAdd,
  TestBackupWithFioOnNewNode, TestBackupAfterNodeMigration,
  TestBackupDuringMigration) into separate get_backup_topology_tests()
  so they don't run in the regular backup pipeline without required
  NEW_NODE_IPS / migrate_to_worker params
- Add "backup-topology" keyword to e2e.py test runner

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Only TestSequentialNodeAdd needs 2 new nodes; all other add-node
tests work with 1.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- csi_repository: add default simplyblock/spdkcsi (was empty)
- csi_tag: add default latest (was empty)
- ifc_names: br-ex:enp2s0f0 (was ens18:enp1s0)
- cluster_environment: openshift-baremetal (was local)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Add cluster_security input (none/backup) to add-node and migration
  workflows (both workflow_call and workflow_dispatch)
- Deploy MinIO + backup-credentials secret when backup is enabled
- Add BACKUP_SPEC to StorageCluster CR for backup-enabled runs
- Auto-detect backup tests by testname containing "Backup"
- Pass cluster_security through topology suite parent workflows

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Remove cluster_security from workflow_dispatch inputs (exceeds GitHub's
25-input limit). Keep it in workflow_call for programmatic use. Backup
is auto-enabled when testname contains "Backup" so no functionality lost.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Change `inputs.tls_enabled == 'true'` to `inputs.tls_enabled` in if
conditions. The truthy check works for both boolean true (from
workflow_call) and string "true" (from workflow_dispatch), avoiding
type coercion issues when parent workflow passes boolean to child.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The DaemonSet schedules storage-node pods on any node with the
simplyblock.io/role=mgmt-plane label. Pre-labeling new_worker_nodes
caused pods to start on nodes not yet in the StorageNodeSet, resulting
in Init:CrashLoopBackOff. The test itself handles labeling when it
adds the node via StorageNodeSet CR update.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Labels persist across pipeline runs. During cleanup, remove
simplyblock.io/role from new_worker_nodes and reset their hugepages
so the DaemonSet doesn't schedule storage-node pods on them before
the test adds them via StorageNodeSet CR.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…elete stuck pods

Three fixes for K8s add-node and migration pipeline failures:

1. Pipeline cleanup: remove /etc/simplyblock from all worker nodes (both
   initial and new) during cleanup phase, preventing stale device config
   from causing init container CrashLoopBackOff on subsequent runs.

2. Add-node test: add new workers one at a time instead of all at once.
   Each node's StorageNode CR is created, stale pods are deleted, and the
   node is waited on to come online before proceeding to the next.

3. Both tests: after creating StorageNode/StorageNodeOps CRs, delete any
   existing simplyblock-storage-node-ds pods on the target worker so the
   DaemonSet recreates them with correct StorageNodeSet configuration.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When creating StorageNode CRs for add-node expansion, read driveSizeRange
and pcieModel from the parent StorageNodeSet and include them in the
overrides block. This ensures the init container can discover the correct
SSD devices on the new worker node.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Root cause: after creating a StorageNode CR, the test immediately deleted the
stale DaemonSet pod. The operator hadn't yet updated the per-node-config
ConfigMap with the new worker's MAX_LVOL value, so the recreated pod started
with MAX_LVOL=0 and crashed in s-node-api-config-generator init container.

Fix: poll the per-node-config ConfigMap until it has an entry for the worker
node before deleting any stale pods. This ensures the DaemonSet recreates the
pod with the correct configuration.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant