Skip to main content

Module image

Module image 

Source
Expand description

Image create, the build wait, and the stalled-build probe (TRAP-1, TRAP-2).

§Why the wait needs a probe at all

CREATING covers two situations that are indistinguishable from the outside: a build in progress, and a build the service never scheduled. The second is the clientToken replay signature — the image was created as a no-op replay of an earlier create, its builds were never queued, it cannot be deleted (CREATING forbids it) and its only version cannot be dropped (it is the last one).

Waiting through it burns the full 45-minute build timeout and then reports “did not become usable in time”, which is a timeout message hiding a cause that was knowable in four minutes. So after WaitOpts::stall_grace the wait probes the build list: every build still PENDING means nothing was ever scheduled, and that is reported as ErrorKind::BuildWedged naming the replay signature.

§The field is buildState

MicrovmImageBuildSummary has no state member. Reading state returns nothing from every real response, which is exactly how this guard was dead for a review round while its unit test passed — see crate::control::ops. The deserializer refuses a state-spelled summary outright, so that failure mode is now a test rather than a comment.

Structs§

Image
A built image, and the log group the service created alongside it.
WaitOpts
How long to wait and how often to poll.

Constants§

BUILD_LOG_GROUP_PREFIX
The log-group prefix the service writes build logs under.
DEFAULT_BUILD_TIMEOUT
The default build timeout, 45 minutes.
DEFAULT_IMAGE_POLL_INTERVAL
The default gap between polls.
DEFAULT_STALL_GRACE
How long an image may sit in CREATING before the stall probe runs.