Skip to main content

yaml_string_mapping

caixa_core::render

Function yaml_string_mapping 

Source 
pub fn yaml_string_mapping<K, V, M>(m: M) -> Value
where
    M: IntoIterator<Item = (K, V)>,
    K: Into<String>,
    V: Into<String>,
Expand description

Convert a typed string-valued mapping (e.g. one of the canonical pleme_program_selector / pleme_program_in_aplicacao_selector selectors, or any caller-built BTreeMap<&'static str, String>) into a serde_yaml::Value::Mapping with String → String shape — the surface every Cilium / Gateway / HTTPRoute / ComputeUnit matchLabels / metadata.labels / selector field expects.

Iteration order is whatever the input iterator yields; pass a BTreeMap for alphabetical determinism (THEORY.md §V.2.7 render determinism: rendered YAML key order is independent of source-code declaration order). The two pleme-io selector helpers above already return BTreeMaps for exactly this reason.

Lifted from caixa-mesh’s prior yaml_string_mapping private helper to make the same primitive available to every other caixa-<target> renderer that needs to emit a string→string YAML mapping (the future per-Aplicacao Gateway-API filter rules, the caixa-otel resource-attribute emitter, the app-operator’s typed CR materializer, the per-cluster CiliumClusterwideEnvoyConfig renderer for :politicas defaults). Without the lift each new renderer would re-inline the same five-line for (k, v) body and inherit the same drift footguns.