Jean-Gabriel Gill-Couture
287ecdfb30
Replaces what would otherwise be a yaml fixture for the hands-on
demo. The CRD is already fully typed (DeploymentSpec + ScorePayload
+ PodmanV0Score + Rollout), so the applier uses those types
directly, constructs the CR via kube::Api, and either applies it
server-side or prints the JSON for `kubectl apply -f -`.
CLI:
iot_apply_deployment \
--namespace iot-demo \
--name hello-world \
--target-device iot-smoke-vm \
--image docker.io/library/nginx:latest \
--port 8080:80 # apply
iot_apply_deployment --image nginx:1.26 # upgrade (same name, new img)
iot_apply_deployment --delete # tear down
iot_apply_deployment --print ... # JSON to stdout → kubectl -f -
Uses server-side apply (PatchParams::apply().force()) so repeated
invocations patch the existing CR cleanly — the upgrade path the
demo exercises.
To expose the CRD types to an external consumer, iot-operator-v0
gains a thin `src/lib.rs` that re-exports the `crd` module. The
binary target now imports from the library (`use iot_operator_v0::crd;`)
instead of declaring its own `mod crd;` — avoids compiling the
types twice.
No change in operator runtime behavior.
Part of the ROADMAP/iot_platform/v0_1_plan.md Chapter 1 work.
20 lines
522 B
TOML
20 lines
522 B
TOML
[package]
|
|
name = "example_iot_apply_deployment"
|
|
version.workspace = true
|
|
edition = "2024"
|
|
license.workspace = true
|
|
|
|
[[bin]]
|
|
name = "iot_apply_deployment"
|
|
path = "src/main.rs"
|
|
|
|
[dependencies]
|
|
harmony = { path = "../../harmony", default-features = false, features = ["podman"] }
|
|
iot-operator-v0 = { path = "../../iot/iot-operator-v0" }
|
|
kube = { workspace = true, features = ["runtime", "derive"] }
|
|
k8s-openapi.workspace = true
|
|
serde_json.workspace = true
|
|
tokio.workspace = true
|
|
anyhow.workspace = true
|
|
clap.workspace = true
|