Differences

This shows you the differences between two versions of the page.

--- zededa:patch-envelopes [2026/07/23 23:11] – mc
+++ zededa:patch-envelopes [2026/07/23 23:24] (current) – mc
@@ Line 14: / Line 14: @@
 attach a patch envelope to the app instance and update //just// that data. Typical scenarios:
-  * Pushing updated configuration to a running app without downtime
+  * Making updated configuration available to a running app without downtime (the app pulls it from the metadata service — nothing is pushed to the guest)
   * Rotating credentials, certs, tokens, license keys
   * Delivering site-specific or device-specific parameters to a generic image
@@ Line 23: / Line 23: @@
 ===== What can the binary artifact be? =====
+You attach one or more **binary artifacts** to a patch envelope and present them to the app
+instance; the app then pulls them from the metadata service. So what can that artifact
+actually be?
 **Anything — it is an opaque blob to EVE.** EVE does not parse, validate, or execute the
@@ Line 31: / Line 35: @@
   * certs, keys, a license file, a token
   * a firmware image, a tarball / zip, a small dataset, a DB seed
+  * a file with **any** extension (''.ext'', ''.bin'', ''.dat'', …) — the extension is meaningless to EVE
   * essentially any file you would otherwise have to bake into the image
@@ Line 87: / Line 92: @@
 > instance (the same ''169.254.169.254'' link-local service used for cloud-init/ECO metadata).
 > An app on a pure switch NI with no local-NI path will not see it.
+==== ⚠ Gotcha — reachability of 169.254.169.254 ====
+The metadata service **lives inside EVE** on the edge node — it is **not** exposed outside the
+node. This has direct consequences for how the workload is networked:
+  * **Local-type NI can reach it; Switch-type cannot.** A **Local** network instance routes to ''169.254.169.254''. A **Switch** NI is pure **layer 2** (a bridge to the physical LAN) and has no path to an address that only exists inside EVE. So the app **must** have an interface on a **Local** NI to hit the metadata service.
+  * **Multi-NIC default-route trap.** If a workload is attached to **two** network instances (e.g. one Local + one Switch, or two with default routes) and **both provide a default gateway**, the guest may pick the **Switch** interface as its default route — and then traffic to ''169.254.169.254'' goes out the wrong interface and **fails**.
+  * **Fix — configure it on the Local network instance, NOT inside the guest.** EVE hands routes to the app through the **Local NI configuration** (advertised to the attached app via the NI's DHCP), not via manual ''ip route'' commands. Add a **static route** for the metadata address on the Local NI so the app always routes metadata traffic via that interface regardless of which one holds the default route. In the ''zedcloud_network_instance'' resource this is the ''static_routes'' block: <code>static_routes {
+  prefix  = "169.254.169.254/32"
+  gateway = "<Local NI gateway IP>"
+}</code> (The NI also has ''propagate_connected_routes'' for auto-propagating its connected routes.)
 **How to detect changes without busy-polling:** fetch ''description.json'' and compare the