manta_shared/types/
dto.rs

1//! Wire response types shared by both binaries.
2//!
3//! The CLI (in `manta_cli::http_client::*` and `manta_cli::output::*`)
4//! deserializes responses from the manta-server using these types;
5//! the server serializes them back over HTTP via the service layer.
6//!
7//! `NodeDetails` is mirrored locally (rather than re-exporting from
8//! `csm-rs`) so `manta-shared` — and therefore `manta-cli` — does not
9//! transitively depend on `csm-rs`. No in-process conversion is
10//! needed: the type boundary is HTTP, and the JSON wire shape is
11//! byte-identical between `csm_rs::node::types::NodeDetails` and the
12//! mirror below (same field names, no `#[serde(rename)]`), so the CLI
13//! just deserializes the response directly into this struct.
14//!
15//! The remaining re-exports come from the lightweight
16//! `manta-backend-dispatcher` crate (types + traits only, no csm-rs
17//! / ochami-rs deps). Mirroring those too is a separate, optional
18//! follow-up.
19
20pub use manta_backend_dispatcher::types::{
21  Group, NodeSummary,
22  bos::session_template::BosSessionTemplate,
23  bss::BootParameters,
24  cfs::{
25    cfs_configuration_response::CfsConfigurationResponse,
26    session::CfsSessionGetResponse,
27  },
28  ims::Image,
29};
30
31use serde::{Deserialize, Serialize};
32use utoipa::ToSchema;
33
34/// Per-node details returned by `GET /api/v1/nodes`.
35///
36/// Mirror of `csm_rs::node::types::NodeDetails` with identical fields
37/// and identical JSON wire format. No conversion impl is needed in
38/// the server crate — the response is serialised straight from the
39/// csm-rs type and the CLI deserialises it into this mirror.
40///
41/// All fields are wire-stringified (CSM serializes them that way);
42/// callers parse them as needed for display or comparison. The empty
43/// string is the conventional "unset" sentinel — see
44/// `cluster_status::compute_summary_status` for case-insensitive
45/// matching on the status fields.
46///
47/// # Wire shape
48///
49/// ```json
50/// {
51///   "xname": "x3000c0s1b0n0",
52///   "nid": "nid001313",
53///   "hsm": "alps,zinal",
54///   "power_status": "On",
55///   "desired_configuration": "cos-2.5",
56///   "configuration_status": "configured",
57///   "enabled": "true",
58///   "error_count": "0",
59///   "boot_image_id": "0a1b2c3d-...",
60///   "boot_configuration": "cos-2.5",
61///   "kernel_params": "console=ttyS0 ..."
62/// }
63/// ```
64#[derive(Debug, Serialize, Deserialize, ToSchema)]
65pub struct NodeDetails {
66  /// Physical location ID, e.g. `x3000c0s1b0n0`.
67  pub xname: String,
68  /// Numeric node ID as a string, e.g. `"nid001313"`.
69  pub nid: String,
70  /// Comma-separated HSM group names this node belongs to.
71  pub hsm: String,
72  /// Current power state reported by PCS (`"On"`, `"Off"`, `"Ready"`,
73  /// etc.).
74  pub power_status: String,
75  /// CFS desired-configuration name targeting this node.
76  pub desired_configuration: String,
77  /// CFS configuration status (`"configured"`, `"pending"`,
78  /// `"failed"`, etc.).
79  pub configuration_status: String,
80  /// `"true"` or `"false"` — whether the node is enabled in the
81  /// hardware state manager.
82  pub enabled: String,
83  /// Stringified count of recent CFS failures.
84  pub error_count: String,
85  /// IMS image ID currently set as the boot image.
86  pub boot_image_id: String,
87  /// CFS configuration linked to the boot image.
88  pub boot_configuration: String,
89  /// Kernel command-line parameters as last reported by BSS.
90  pub kernel_params: String,
91}