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}