Node pool UI/API rough edges (architecture casing, validation messages, units, MIG display)

Found while testing node pool add / update / archive through the UI on staging (26.10.0-rc3, 2026-10-26). Add, update and archive all work (POST 201, PUT 204, archive 204; UI and API agree); these are the rough edges.

  1. Architecture casing. The form sends x86_64; the API returns "X86_64" everywhere (list, single pool, site). The runner serializes the enum name on purpose (legacy marshmallow format), but the spec's RunnerNodeArchitecture enum and the front type say x86_64/arm64, and the table shows X86_64 next to a form offering x86_64. Pick one and make spec, API and UI agree.

    let's use lower-case x86_64 everywhere

  2. No validation messages for min/max. The error templates only cover required. CPU < 100 mCPU, memory < 1 GB or a score > 100 disable Create and outline the field in red, with no text saying why.

    Add a validation text to explain the limits

  3. Units. CPU is entered in mCPU but the table's CPU column shows cores without a unit (100 → 0.1). Memory is entered in whole GB (minimum 1 GB). The front sends memory in bytes, while the API spec describes memory as "Size of memory in GB".

    Fix API to make the possibility to send raw int for memory bytes, and cores. Also accept units for memory (MB,GB,TB) and for core (100m for 100 millicore), adapt the spec accordingly. Also, allow users to use these notations in the front and add helping text next to the form field in nodepool creation. Regarding the display keep core and GB units.

  4. CPU, memory and architecture cannot be edited after creation (not in the Edit modal, not in UpdateNodePoolRequest). Confirm it is intended, and say so in the UI.

    Explain in the UI with a note that node pool resources cannot be modified after creation, user should archived and create another.

  5. MIG pools show GPU "-" in the table, though they have gpu_count 7/2/1, a gpu_mode (mig-1g.10gb, ...) and filter_no_gpu_action: true: the table only shows a GPU when gpu_model is set, and these pools have gpu_model: null.

    Migration of the existing GPU pool on the new format leave old entries with no gpu model. Manage the case in the front if possible (would be better, not something that happen twice) or force the admin to set these fields in the upgrade process add make the upgrade process.

  6. API inconsistencies. A pool created without GPU has gpu_count: null, the older default pool has 0 (see the scheduler crash issue).

    already managed in #1481 (closed)

  7. An archived pool is still returned by GET /api/runner/node-pools/{id} with 200 and nothing marking it archived.

    add a filter by default on archived

  8. Archive confirmation reads "Are you sure to archive node pool ?": it doesn't name the pool and the wording is off.

    Add the name and id of the node pool on the message and fix the wording

Edited by Michael Mercier