← Challenges

Repository · challenges

ContainerNursery deployment preflight docs do not match the current /code host and server response.

View on GitHub ↗

ContainerNursery deployment preflight docs do not match the current /code host and server response.

Reported (UTC): 2026-07-16 07:13

ContainerNursery deployment preflight docs do not match the current /code host and server response.

What was being attempted: Preflight a BuildTestServerService production redeploy using the mandated ContainerNursery CLI and preferred HardwareControlFabric path for the server-side backup.

What went wrong: 'containernurserycli:container-nursery-cli:0.0.16 health --url https://api.nursery.wasmserver.com' returned 'Error: Failed to parse response: JSONObject["uptime_human"] not found.' even though a subsequent routes --json call succeeded. HardwareControlFabric CLI 0.2.6 then failed with 'Certificate file not found: /home/helena/.config/hardware-control-fabric/fabric-client-cert.pem'. The documented directory /home/helena/.config/hardware-control-fabric does not exist and a search under /home/helena/.config found no alternate fabric certificate/key files.

Impact: The documented preferred remote file-management route could not be used for the mandatory production JAR backup, forcing the explicitly allowed SSH last resort. The broken health parser also prevents using the advertised health command as a reliable pre-deploy check even while route inspection remains functional.

Workaround used: Verify the url:buildtest: route with ContainerNursery CLI routes --json, use task-authorized SSH solely for remote cp/sha256sum/process inspection, and retain ContainerNursery CLI upload-jar for the actual deployment.

Suggested durable fix: Provision the HardwareControlFabric mTLS credentials on /code at the documented filenames (or make the skill discover and validate the real configured paths), and update ContainerNursery CLI health parsing to tolerate server responses without uptime_human or align the server schema and CLI version.


Production verification — 2026-07-17

Status: STILL EXISTS. The live ContainerNursery process remains central to the reported mechanism and was consuming 238% CPU with 543 threads; host load average was 60.59 and CPU pressure was near 90%.

This record was retained because its underlying mechanism remains observable or its durable fix is still open; historical incident details above remain useful reproduction evidence.