/alibabacloud-pai-node-management

name: alibabacloud-pai-node-management
domain: aiops
description: |
  Manage Alibaba Cloud PAI compute Nodes — list nodes within a ResourceGroup or Quota,
  inspect a node's status, hardware spec (GPU / CPU / memory) and resource usage, and
  perform safety-gated maintenance operations (cordon, uncordon, drain) with explicit
  two-step confirmation. Use when the user asks to list / get / inspect PAI nodes, check
  node status, find a node's MachineGroup or ResourceGroup, or cordon / uncordon / drain
  a node. Out of scope: node power changes (start / stop / reboot), node replacement /
  migration, per-node GPU metrics, and per-node pod listing — these are platform-managed
  and require escalation to the platform Ops team / Lingjun ops ticket / account manager.
  Trigger phrases: "PAI node", "list nodes", "node status", "GPU node", "Lingjun node",
  "cordon node", "uncordon node", "drain node", "isolate node for maintenance",
  "PAI 节点", "查看节点", "隔离节点", "恢复节点".
required_permissions:
  - pai:ListNodes
  - pai:GetResourceGroup
  - pai:ListResourceGroups
  - pai:ListQuotas
  - pai:GetQuota
  - pai:UpdateResourceGroup
  - pai:UpdateQuota

PAI Node Management

0. Observability (MUST follow for every aliyun command)

Upon loading this skill, generate a random session ID (32-char hex string) once for the entire session. Use it as `{session-id}` below.

**Rule: Every `aliyun` CLI command that calls a cloud API MUST include the `--user-agent` flag.** Local utility commands (e.g. `configure`, `plugin`, `version`) do not support this flag and should be excluded.

--user-agent AlibabaCloud-Agent-Skills/alibabacloud-pai-node-management/{session-id}

Example (assuming session-id is `a]1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6`):

aliyun ecs describe-instances --biz-region-id cn-hangzhou --user-agent AlibabaCloud-Agent-Skills/alibabacloud-pai-node-management/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6

Do not skip, alter the format, or omit `--user-agent` on any `aliyun` command invocation.

**Plugin freshness (one-time per session, optional system command — NO `--user-agent`):**

aliyun plugin update

Every command omits the `--user-agent` flag for readability. **The agent MUST append it to every actual business API invocation** following the rules above. Missing or malformed `--user-agent` on a business API call is a workflow violation.

1. Scenario

Inspect and operate Alibaba Cloud PAI **Nodes** via the `aliyun paistudio` CLI plugin: enumerate nodes, single-node detail lookup, and **cordon / uncordon / drain**. Hierarchy: `ResourceGroup → MachineGroup → Node(s)`.

**Out of scope** (refuse outright; do NOT route to alternative transports — see `references/not-implementable.md` and `references/refusal-patterns.md`):

• Node power (start / stop / reboot), replace, migration.
• MachineGroup deletion / release.
• Per-node metrics (`get-node-gpu-metrics`) and per-node pod listing (`list-node-pods`) — not in public CLI.

> 🚧 **[Nodes are platform-managed — neither user nor agent has node-level direct access.]** PAI Nodes are platform-managed resources; users and the agent MUST NOT and CAN NOT operate inside a node or against a node object directly (no host login, no cgroup edits, no direct pod eviction, no cordoning the node object directly, no label/taint mutation, no force-release of the underlying hardware). All node operations MUST flow through `aliyun paistudio operate-node` via the PAI control plane — node objects are an opaque black box from the user/agent perspective. Any "bypass the control plane and reach the node directly" approach is unauthorised, regardless of the tool name. Explicitly forbidden as fallback paths include but are not limited to: `kubectl cordon` / `kubectl drain` / `kubectl get nodes` / SSH to the node / `nvidia-smi` / direct cgroup access / direct Kubernetes apiserver calls / any node-level direct-access scheme. Even if the user asks for it, the agent MUST NOT echo such commands or hint at them in any reply. The only legitimate escalation path for node-level intervention is the platform Ops team (Lingjun ops ticket / account manager).

> 🗣️ **[MANDATORY REFUSAL WORDING]** Every refusal reply for out-of-scope / blocked operations MUST explicitly cite the **platform Ops team** as the only escalation channel and MUST list the three-way escalation: **platform Ops team / Lingjun ops ticket / account manager**. See `references/refusal-patterns.md`. All wording in refusals must be in English. > > 🚫 **[Forbidden literal-string rule for node power / reboot refusals]** When the user requests node power / start / stop / reboot / restart / power-cycle, the agent MUST refuse and point to the three-way escalation. The refusal text (explanatory paragraphs, refusal blocks, output files, reference links, few-shot replays, counter-example code blocks) MUST NOT contain the following literal strings — neither in backticks nor as inline `<code>`, shell examples, nor as "negative" examples in narrative: > > - `aliyun ecs reboot-instance` / `aliyun ecs start-instance` / `aliyun ecs stop-instance` (kebab-case CLI form) > - `RebootInstance` / `StartInstance` / `StopInstance` (CamelCase / SDK form) > - Any fabricated `aliyun paistudio reboot-node` / `restart-node` / `power-cycle-node` > - Any node-level direct-access fragment such as `kubectl` / `ssh` / `nvidia-smi` > > Even when explaining "why this is not feasible" / "I cannot call X to reboot the node" / "and I cannot fall back to Y", the moment those strings appear in executable form they imply the path is viable = guide the user to attempt = unauthorised guidance. Correct approach: state in plain English that *"Node power-state changes (start / stop / reboot) are out of scope for this skill, and the only legitimate path is the platform Ops team / Lingjun ops ticket / account manager"*, and never display any concrete CLI / SDK / tool command. The agent knows these commands exist (from internal skill rules), but MUST NOT