pub struct MicrovmImageVersionSummaryWire {Show 18 fields
pub base_image_arn: String,
pub build_role_arn: String,
pub code_artifact: CodeArtifact,
pub image_arn: String,
pub image_version: String,
pub state: String,
pub status: String,
pub created_at: f64,
pub base_image_version: Option<String>,
pub description: Option<String>,
pub resources: Option<Vec<Resources>>,
pub cpu_configurations: Option<Vec<CpuConfiguration>>,
pub egress_network_connectors: Option<Vec<String>>,
pub additional_os_capabilities: Option<Vec<String>>,
pub environment_variables: Option<BTreeMap<String, String>>,
pub updated_at: Option<f64>,
pub state_reason: Option<String>,
pub tags: Option<BTreeMap<String, String>>,
}Expand description
MicrovmImageVersionSummary, which is also GetMicrovmImageVersionOutput and
UpdateMicrovmImageVersionResponse — the three shapes are member-for-member identical
in the model, so one type serves all of them.
One type rather than three for the reason MicrovmResponseWire gives: a second copy
is a second place to keep twenty member spellings right, and the model itself declares
them as one set. Checked member-by-member against service-2.json on 2026-08-16 —
GetMicrovmImageVersionOutput, UpdateMicrovmImageVersionResponse, and
MicrovmImageVersionSummary list the same twenty members with the same eight required.
Note state here is the member’s name — unlike the build summary below, and that
asymmetry is the whole trap.
§All eight required members, not the four this crate reads
The same argument MicrovmImageBuildSummaryWire records: the model marking a member
required is the strongest promise it makes about a response, and a required member absent
from the struct is one no drift check can notice going missing. status in particular was
Option<String> while the model requires it — so a service that stopped sending the
availability status would have read as None, which is exactly how a version blocked from
launching would look identical to one nobody had ever set. Confirmed present on all 22
versions in the conformance account (2026-08-16), so requiring it is a measurement rather
than a reading of the model alone.
§hooks is deliberately not here, and the reason is a measurement
The model marks every member of Hooks, MicrovmHooks, and MicrovmImageHooks optional,
while this module’s request-side Hooks declares them all as bare fields — correct for
a request, since this client always sends all six. A real response is not so generous:
GetMicrovmImageVersion on an image built by another tool answered
"microvmHooks": {"run": "ENABLED", "runTimeoutInSeconds": 30} and nothing else
(measured 2026-08-16, us-east-1, omnigent-host-vpc version 3.0), so five of
MicrovmHooks’s eight members were absent. Reusing Hooks here would fail that parse
and turn a readable version into a client error. A response-shaped hooks type is the fix
if a caller ever needs it; until then the absence is the honest option, and the test
a_versions_hooks_block_is_not_read_because_a_real_one_omits_members pins the reason.
Fields§
§base_image_arn: String§build_role_arn: String§code_artifact: CodeArtifact§image_arn: String§image_version: String§state: String§status: StringMicrovmImageVersionStatus: ACTIVE or INACTIVE.
A String rather than a VersionStatus, because this is a response and a third
value AWS adds must parse rather than fail — the same rule
MicrovmImageBuildSummaryWire::architecture follows. VersionStatus is for the
request, where narrowing turns a typo into a compile error.
created_at: f64Epoch seconds, possibly fractional.
base_image_version: Option<String>The base version this version was pinned to, when one was.
The readback for CreateMicrovmImage.baseImageVersion, and the reason pinning is
worth doing: an unpinned build still reports one here, and the value the service
echoes is spelled differently from anything the base’s own listing offers
("1.0" against the managed base’s "0"/"1" — docs/PLATFORM.md). So this is the
record of what was built, not a value to feed back into a request.
description: Option<String>§resources: Option<Vec<Resources>>ResourcesList, max 1. The only place a built image’s size class is observable:
GetMicrovm carries no memory figure at all.
cpu_configurations: Option<Vec<CpuConfiguration>>§egress_network_connectors: Option<Vec<String>>The image-level egress list. Max 1 in the model, not the 10 the VM-level
NetworkConnectorList allows — see crate::constants::MAX_IMAGE_EGRESS_CONNECTORS.
additional_os_capabilities: Option<Vec<String>>§environment_variables: Option<BTreeMap<String, String>>§updated_at: Option<f64>§state_reason: Option<String>The version-level failure reason. Measured null on real failures while the
build-level one is populated — docs/PLATFORM.md, “A failed build’s stateReason
lives on the build”.
Implementations§
Source§impl MicrovmImageVersionSummaryWire
impl MicrovmImageVersionSummaryWire
Sourcepub fn is_active(&self) -> bool
pub fn is_active(&self) -> bool
Whether RunMicrovm will launch this version.
A comparison against the model’s spelling through VersionStatus rather than
against a literal here, so the two cannot drift: the request type and the readback
agree on what "ACTIVE" is spelled like or neither compiles.
Sourcepub fn describe(&self) -> String
pub fn describe(&self) -> String
The version, its state, its availability status, and the reason when the service gave one — the line a retire or a rollback prints.
An absent reason renders nothing rather than an empty parenthesis, for the reason
MicrovmImageBuildSummaryWire::describe gives.