@ornncompute/cli 0.1.6 → 0.1.8

package/README.md

@@ -56,11 +56,14 @@ ornn nodes keys list <node-id> [--json]
 ornn node health <node-id> [--json]
 ornn node diagnose <node-id> [--json]
 ornn node deenroll <node-id> [--reason <text>] [--keep-record] [--json]
-ornn fleet clean <ip>... --operator <id-or-slug> --ib-island <name> --identity-file <path> --dry-run [--source-user <user>]... [--preserve-user <user>]... [--ssh-user ubuntu|admin|ornn] [--json]
-ornn fleet clean <failed-fleet-id> --identity-file <path> --dry-run [--source-user <user>]... [--preserve-user <user>]... [--json]
-ornn fleet clean <fleet-id> --identity-file <path> --confirm-clean <plan-hash> [--source-user <user>]... [--preserve-user <user>]... [--json]
+ornn fleet clean <ip>... --operator <id-or-slug> --ib-island <name> --identity-file <path> --dry-run [--policy <path>] [--policy-out <path>] [--ssh-user ubuntu|admin|ornn] [--json]
+ornn fleet clean <fleet-id> --identity-file <path> --dry-run [--policy <path>] [--policy-out <path>] [--json]
+ornn fleet clean <fleet-id> --identity-file <path> --confirm-clean <plan-hash> [--json]
 ornn fleet enroll <fleet-id> --identity-file <path> [--confirm-takeover <ip[,ip...]>] [--json]
-ornn fleet deploy <fleet-id> --tenant <contact-email> --user <email-or-id> [--commerce-reservation <id>] [--network public|private] [--json]
+ornn fleet delete <fleet-id> --confirm-delete <fleet-id> [--json]
+ornn reservations commerce list --tenant <email-or-id> [--fleet <fleet-id>] [--json]
+ornn reservations commerce create --tenant <email> --listing <listing-id> --fleet <fleet-id> [--start-at <timestamp>] [--end-at <timestamp>] [--price-per-gpu-hour <rate>] [--json]
+ornn fleet deploy <fleet-id> --tenant <contact-email> [--user <email-or-id>] --commerce-reservation <id> [--network public|private] [--json]
 ornn ssh <node-or-reservation-id> [--print] [--identity-file <path>] [--user <name>] [--json]
 ornn metrics nodes [--json]
 ornn metrics node <node-id> [--json]
@@ -103,9 +106,9 @@ ornn storage volumes create --name <name> [--source <drive-id>] [--json]
 ornn storage volumes refresh <drive-id> [--json]
 ornn storage volumes clear <drive-id> [--json]
 ornn storage volumes delete <drive-id> [--json]
-ornn storage deploy <drive-id> --reservation <reservation-id> [--mount-path <path>] [--read-only|--read-write] [--json]
+ornn storage files upload <drive-id> <local-file> [--destination <path>] [--content-type <type>] [--json]
+ornn storage deploy <drive-id> --reservation <reservation-id> [--all-nodes] [--mount-path <path>] [--read-only|--read-write] [--json]
 ornn storage deploy status --reservation <reservation-id> [--json]
-ornn storage unmount --reservation <reservation-id> [--json]
 ornn storage undeploy --reservation <reservation-id> [--json]
 ornn storage buckets list [--json]
 ornn storage buckets show <drive-id> [--json]
@@ -143,8 +146,23 @@ current user's complete reservation key set on those machines. Use
 `ornn access keys push` to explicitly re-sync keys that are already attached.
 
 `ornn storage deploy status` prints reconciled object and byte progress once the
-managed transfer has reported progress. AWS S3 and external GCS sources use the
-managed transfer path. Cloudflare R2 support is coming soon.
+managed transfer has reported progress, plus the number of target nodes that
+have acknowledged the mount. Internal placement bucket details are not shown.
+AWS S3 and external GCS sources use the managed transfer path. Cloudflare R2
+buckets can be connected and verified, but deployment support is coming soon.
+
+`ornn storage files upload` adds a file to the drive's current colocated copy.
+You can upload while a direct FUSE mount is active; every mounted node sees the
+file on its next lookup without a remount. A direct FUSE drive attaches to one
+reservation by default; pass `--all-nodes` on `ornn storage deploy` to fan the
+same mount out across every compatible node in the node group. Avoid writing
+the same file path concurrently from multiple nodes because object storage is
+not a POSIX shared filesystem.
+
+For a connected bucket, deploy once before uploading. The first deploy imports
+the source into an Ornn-managed colocated working copy. That copy remains the
+drive's durable data when you unmount, detach, or mount it elsewhere. Ornn
+does not write changes back to the original connected bucket.
 
 UI aliases are first-class in the CLI: `listings` maps to the older
 `availability` command, `exchange` maps to `bid`, and `gpus` maps to
@@ -200,7 +218,7 @@ The operator resource commands share the same reviewer auth:
   filtered to one operator.
 - `ornn tokens list` lists enrollment tokens.
 - `ornn tokens create --operator <id> [--facility <id>]
-  [--expires-in <seconds>] [--mode bare-metal|vm] [--ip <addr>]` mints an
+[--expires-in <seconds>] [--mode bare-metal|vm] [--ip <addr>]` mints an
   enrollment token and prints a ready-to-run `curl … | sudo bash` install
   command.
 - `ornn tokens revoke <token-id>` revokes an enrollment token.
@@ -210,33 +228,72 @@ Fleet handoff is an ordered, Compute-backed workflow:
 - Before first contact, independently verify each host key and add it to the
   operator's SSH `known_hosts`; fleet SSH uses strict host-key checking and will
   not trust a key first presented during cleanup.
-- `fleet clean ... --dry-run` tries `ubuntu`, `admin`, then `ornn`, records each
-  host's hardware identity and exact deletion plan, and prints one fleet plan
-  hash. Repeat `--source-user` for Linux accounts owned by the departing tenant
-  (including an explicitly reviewed orphaned `/home/<user>` directory) and
-  `--preserve-user` for reviewed host accounts. Package/service-owned
-  accounts are protected automatically; any other account stops planning for
-  explicit review. Re-running with `--confirm-clean <plan-hash>` and the same
-  account flags removes the approved tenant
-  users, keys, containers/images/volumes/networks/build cache, workload paths,
-  mounts, services, and tenant-scoped logs. Apply refuses plans with running
-  containers, locks the management/root passwords, enforces key-only SSH, trims
-  supported filesystems, preserves existing root and management keys and host
-  logs, and stores per-node proof in Compute. A failed
-  cleanup can be dry-run again with the same fleet ID; only failed members are
-  replanned. Residual GPU
-  consumers or tenant/platform listeners fail verification instead of being
-  silently accepted.
+- `fleet clean ... --dry-run` tries `ubuntu`, `admin`, then `ornn`, binds the
+  inventory to the host's hardware identity, records the plan in Compute, and
+  writes an editable mode-`0600` policy beside the local fleet manifest (or to
+  `--policy-out`). Inventory covers accounts and orphan homes, authorized SSH
+  keys, tenant/log/temp/platform paths, workload and listener processes, GPU
+  consumers, custom systemd services, Docker/Podman objects and bind-mount
+  dependencies, and every block drive. Each resource advertises its own valid
+  actions. Suggestions are never applied silently: unresolved choices and
+  conflicts are recorded as plan data, so edit the policy and re-run the same
+  fleet with `--policy`; planning is not terminalized just because a choice is
+  needed. `--source-user` and `--preserve-user` remain legacy user-only
+  shortcuts and cannot be mixed with a policy file.
+- `fleet clean <fleet-id> ... --confirm-clean <plan-hash>` is shown only after
+  every choice is resolved. Execution rechecks hardware and resource identity,
+  runs an idempotent per-resource journal, preserves the management SSH key,
+  enforces key-only SSH, and returns exact deleted, preserved, exception, and
+  drive-assurance evidence. `ignore` requires a reason and produces
+  `clean_with_exceptions`; it is never reported as residue-free deletion.
+  Data-drive actions are selectable: `logical_clean`, `discard`, `sanitize`, or
+  `reformat`. The system drive and drives without a unique serial/WWN are
+  locked to keep/ignore for in-band cleanup. `sanitize` requires NVMe plus
+  controller-reported completion. Logical cleanup, discard, and reformat are
+  not certified physical-media erasure, and the system drive requires an
+  out-of-band reimage for that assurance.
+  If the local SSH command times out while a long device operation is still in
+  progress, the recorded run remains resumable; re-run the same
+  `--confirm-clean <plan-hash>` command instead of creating a different plan.
+  Plans created by a pre-v6 runner must be replanned with `--dry-run` before
+  approval. This keeps newly discovered resources bound to a fresh reviewed
+  hash instead of adapting a legacy account-only plan during execution.
+
+In the generated policy, change only `action`, plus `reason` for `ignore` or
+`replacement` for `replace`; keep each generated `identity_hash` intact. `keep`
+leaves a resource running, `stop_keep` stops but retains it, `stop` terminates a
+process, `delete` removes it, `restart` restarts a service, and `replace`
+recreates a container from the supplied image/name/network/command/labels/mounts
+specification. The generated `suggested_action` is review guidance, not an
+automatic decision. Do not put secrets in replacement commands or labels; use
+the platform secret manager or a reviewed secret mount.
+
 - `fleet enroll <fleet-id>` refuses nodes without successful cleanup proof,
   issues and revokes one cleanup-bound token per host, installs the agent,
   assigns the IB island, verifies the same management account still has
   key-based SSH and passwordless sudo, and records the resulting GPU node IDs
   in Compute. Generic enrollment tokens retain the legacy enrollment sanitizer.
-- `fleet deploy <fleet-id> --tenant <contact-email> --user <email-or-id>
-  [--commerce-reservation <id>]` validates the exact tenant/user and, when
-  supplied, the Commerce reservation. It succeeds only after every selected
-  user's SSH key is installed on every running node and passwordless sudo is
-  reported ready.
+- `fleet delete <fleet-id> --confirm-delete <fleet-id>` hard-deletes only an
+  abandoned cleanup plan or an unassigned legacy enrollment record. It saves a
+  local audit manifest first and refuses any Commerce/tenant/deployment link,
+  active enrollment, assigned GPU node, or completed/running cleanup evidence.
+  It never deletes the linked GPU-node records.
+- `reservations commerce create --tenant <email> --listing <listing-id>
+--fleet <fleet-id>` creates and activates the tenant's Commerce reservation.
+  GPU count comes from the enrolled fleet; start, end, and hourly rate default
+  from the listing. Start and end overrides must remain inside the listing's
+  allowed window; the hourly rate can also be overridden explicitly.
+- `reservations commerce list --tenant <email-or-id> [--fleet <fleet-id>]`
+  lists active reservations in their live window; with `--fleet`, it returns
+  only reservations whose listing exactly matches that fleet's operator,
+  facility, GPU model, per-node size, and total GPU count.
+- `fleet deploy <fleet-id> --tenant <contact-email>
+[--user <email-or-id>] --commerce-reservation <id>` requires a live,
+  tenant-owned Commerce reservation whose listing exactly matches the fleet.
+  The user defaults to the tenant's primary administrator. Deployment succeeds
+  only after that user's SSH access and passwordless sudo are ready on every
+  node; Commerce is stamped only after the entire fleet reports deployed. A
+  Commerce reservation can be linked to only one fleet.
 
 Compute Postgres is authoritative; the mode-0600 files under
 `~/.config/ornn/fleets/` are only a secret-free cache. Cleanup proves “no
@@ -248,17 +305,22 @@ control-plane policy.
 
 Reservation lifecycle verbs also run under the operator surface:
 
+- `ornn reservations commerce create|list` creates or discovers a validated
+  Commerce reservation for an enrolled fleet. These actions require a staff
+  `ornn login`; the direct review-secret path cannot bypass Web validation.
 - `ornn reservations withdraw <reservation-id>` withdraws a reservation's
   acceptance, returning the node(s) to tenant inventory.
 - `ornn reservations transfer <reservation-id> --target-tenant <id>
-  [--target-user <id>] [--node <id>] [--strategy reject|park] [--confirm]`
+[--target-user <id>] [--node <id>] [--strategy reject|park] [--confirm]`
   transfers a reservation to another tenant.
-- `ornn reservations deploy <node-id> --target-tenant <id> [--target-user <id>]
-  [--network public|private]` deploys a node into a tenant's inventory.
+- `ornn reservations deploy <node-id> --target-tenant <id>
+--commerce-reservation <id> [--target-user <id>] [--network public|private]`
+  deploys one node only after Web verifies that the live tenant-owned Commerce
+  reservation and listing match that node.
 
 The tenant `ornn reservations list|show|checkout` verbs still use the tenant CLI
-login and `/api/cli` proxy; `withdraw|transfer|deploy` use the operator path
-above (staff session proxy or optional review secret).
+login and `/api/cli` proxy. Staff Commerce actions use the Web operator proxy;
+`withdraw|transfer|deploy` retain the operator path above.
 
 Staff happy path:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ornncompute/cli",
-  "version": "0.1.6",
+  "version": "0.1.8",
   "description": "Command-line interface for Ornn compute access workflows.",
   "type": "module",
   "bin": {

package/src/api-client.mjs

@@ -271,6 +271,28 @@ export async function operatorRequest({
   );
 }
 
+/**
+ * Commerce-backed operator actions must cross the Web trust boundary. Web
+ * validates Commerce state before it forwards to Compute, so direct
+ * review-secret access is intentionally unavailable for these requests.
+ */
+export async function webOperatorRequest({
+  body,
+  endpoint,
+  env = process.env,
+  fetchImpl = fetch,
+  method = "GET",
+} = {}) {
+  const session = await loadAuthSession({ env });
+  if (!session?.accessToken) {
+    throw new CliApiError(
+      "Commerce-backed deployment requires Ornn staff auth through Web. Run `ornn login` first.",
+      { status: 401 },
+    );
+  }
+  return operatorRequestViaStaffSession({ body, endpoint, env, fetchImpl, method });
+}
+
 export function computeEndpoint(path) {
   const normalized = normalizeComputePath(path);
   return `/api/cli/compute${normalized}`;
@@ -341,6 +363,9 @@ function detailMessage(detail) {
   if (!detail || typeof detail !== "object") {
     return "";
   }
+  if (typeof detail.message === "string") {
+    return detail.message;
+  }
   if (typeof detail.summary === "string") {
     return detail.summary;
   }