Skip to content

ADR rpc health readiness status command

Jump to bottom
DevipriyaS17 edited this page Jun 17, 2026 · 1 revision

ADR: RPC Health / Readiness Command (Pre + Post Activation)

Context

Issue: https://github.com/device-management-toolkit/rpc-go/issues/1244

A single command is required to address two distinct questions:

  • Pre-activation: can provisioning start safely now?
  • Post-activation: is the activated device fully manageable in production?

Today these answers are assembled manually from multiple places (rpc amtinfo, local service checks, network checks, remote checks), which leads to inconsistent triage and repeated deployment failures.

Solution

Adopt one command with one output contract:

Note: One of the three commands below needs to be finalized

  • rpc status
  • rpc health
  • rpc doctor

All aliases map to the same command behavior.

The command supports two phases:

  • Phase A (pre-activation): readiness-to-provision checks.
  • Phase B (post-activation): manageability-health checks.

The command outputs:

  • human-readable text (operator focused)
  • JSON (automation focused)
  • A clear phase-specific final outcome

Command Interface

Current command names

  • ./rpc status
  • ./rpc health
  • ./rpc doctor

Phase selection model

Proposed mode syntax:

  • ./rpc health --mode auto (default)
  • ./rpc health --mode pre
  • ./rpc health --mode post

Notes:

  • --mode pre forces pre-activation checks.
  • --mode post forces post-activation checks.
  • --mode auto selects phase by detected device state.

High-Level Architecture

User / Automation
    |
    | rpc health [--mode auto|pre|post] [--json]
    v
StatusCmd
    |
    +--> command initialization context
    |      - platform/runtime setup
    |      - control state detection
    |
    +--> phase selector
    |      - pre path
    |      - post path
    |      - auto path
    |
    +--> phase check engine
    |
    +--> text/json renderer

Phase A architecture (pre-activation)

PreCheckEngine
  ├─ Platform readiness checks
  │   ├─ AMT interface availability
  │   └─ activation state compatibility
  ├─ Identity/profile checks
  │   ├─ DNS consistency
  │   └─ device class compatibility (vPro vs ISM)
  ├─ Local prerequisites
  │   └─ LMS reachability
  └─ Network prerequisites
      ├─ wired/wireless link health
      └─ optional target reachability

Phase B architecture (post-activation)

PostCheckEngine
  ├─ Activated state validity checks
  ├─ Tunnel/session checks (e.g., CIRA health)
  ├─ Security posture checks (certificate/trust state)
  ├─ Feature policy checks (KVM/SOL/IDER/consent profile)
  └─ Remote manageability reachability checks

End-to-End Flow

Pre-activation flow

sequenceDiagram
  autonumber
  participant U as User
  participant C as CLI
  participant I as Command Init
  participant P as PreCheckEngine
  participant A as AMT Local Interfaces
  participant O as OS
  participant L as LMS

  U->>C: rpc health --mode pre
  C->>I: initialize context
  I-->>C: runtime + control state
  C->>P: execute pre checks

  P->>A: platform/profile checks
  P->>O: OS context checks
  P->>L: local manageability checks
  P->>P: compute pre result
  P-->>U: text/json + pre outcome
Loading

Post-activation flow

sequenceDiagram
  autonumber
  participant U as User
  participant C as CLI
  participant I as Command Init
  participant Q as PostCheckEngine
  participant A as AMT Activated State
  participant R as Remote Infrastructure

  U->>C: rpc health --mode post
  C->>I: initialize context
  I-->>C: runtime + activation state
  C->>Q: execute post checks

  Q->>A: state/session/security/feature checks
  Q->>R: remote reachability checks
  Q->>Q: compute post result
  Q-->>U: text/json + post outcome
Loading

Existing Foundation and Evolution

Mike's baseline POC:

This ADR keeps that foundation and extends the command concept to a full dual-phase model.

Implementation Alignment

  • Current code already provides limited pre-activation baseline behavior.
  • This ADR defines the target extension and for post-activation behavior with the same command.

Auto Mode

In --mode auto, the command determines whether to run pre-activation or post-activation checks based on device state.

  1. Primary signal

    • If AMT is not activated → run pre-activation checks
    • If AMT is activated → run post-activation checks

  2. Fallback (ambiguous state)

    • Default to pre-activation (safe fallback)
    • Emit warning in output

Sample Output

Command: sudo ./rpc health

Output :

 AMT Provisioning Readiness
  ──────────────────────────
  ✓  MEI driver present (AMT device)    MEI/HECI driver detected
  ✓  Control mode                       pre-provisioning (ready to activate)
  ○  DNS suffix (AMT vs OS)             AMT DNS suffix not configured
  ✓  AMT device type                    Intel vPro (AMT Pro Corporate)
  ✓  LMS (Local Manageability Service)  listening on localhost:16992
  ✓  Wired network link                 connected
  ○  Wireless network link              disconnected

  ╭────────────────────────────────────╮
  │ AMT device ready to be provisioned │
  ╰────────────────────────────────────╯
  • No mode specified → defaults to --mode auto
  • Device detected as not activated
  • Pre-activation checks are executed

References

Clone this wiki locally