@ornncompute/cli 0.1.5 → 0.1.7

package/README.md

@@ -56,11 +56,13 @@ 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 [--ssh-user ubuntu|admin|ornn] [--json]
-ornn fleet clean <failed-fleet-id> --identity-file <path> --dry-run [--json]
-ornn fleet clean <fleet-id> --identity-file <path> --confirm-clean <plan-hash> [--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 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 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 +105,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 +145,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 +217,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.
@@ -212,11 +229,17 @@ Fleet handoff is an ordered, Compute-backed workflow:
   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. Re-running with `--confirm-clean <plan-hash>` removes the approved tenant
+  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 logs; locks preserved-account passwords, enforces
-  key-only SSH, trims supported filesystems, pins the preserved management
-  account to the supplied key, and stores per-node proof in Compute. A failed
+  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
@@ -226,11 +249,22 @@ Fleet handoff is an ordered, Compute-backed workflow:
   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.
+- `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
@@ -242,17 +276,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.5",
+  "version": "0.1.7",
   "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;
   }