[0xmc]

Summary

A standard container image deployed from a manifest into the unikernel class never starts, and the instance reports a misleading pull error.

Flag deploys already refuse that mismatch up front, but manifest deploys skipped the check, and neither the help nor the plan said which class a workload lands in by default.

Manifest deploys now check every image against the class the workload will run in, the plan names that class, and the help explains how the default is chosen. The misleading message itself comes from the runtime provider and is tracked in datum-cloud/unikraft-provider#257.

Test plan

• A manifest deploy of a standard image into the unikernel class, set or defaulted, is refused with a fix that names the manifest field
• A Compute image in the unikernel class, and a standard image in the general purpose class, still deploy
• The plan for a new workload names its runtime class, including the platform default

Fixes #619

🤖 Generated with Claude Code

[ecv]

Approve.

Extends the existing image/runtime-class preflight to manifest deploys and names the default class in the plan. It fails open on every lookup error, so it cannot block a deploy on registry or catalog trouble.

• Network: build.ImagePlatforms does one remote.Get per container with the local keychain, the same call the flag path already makes. Credentials go only to the image's own registry. Containers are checked serially and deployFromFile uses context.Background(), so an unreachable registry waits out go-containerregistry's transport timeouts per container before failing open. Bound it with a short per-image timeout.
• checkManifestImages falls back to the catalog default when the manifest and the existing workload both have no class. planRuntimeClass states that an existing workload with no class "predates runtime classes" and leaves it unnamed, so the two disagree: redeploying a legacy classless workload with a container image on a unikernel-default catalog would be refused with no override. Confirm what admission does for an update with an empty class; if it keeps it classless, skip the check when existing has no class.
• Only Sandbox.Containers are checked; a manifest without a sandbox is left to admission. Fine.

Follow-ups:

• There is no flag to skip the preflight (for example a mirror whose index lacks Compute platforms). Today the only escape is changing class; consider --skip-image-check.
• Add a test for the unreachable-registry path in checkManifestImages (platforms returns an error, deploy proceeds).