ZEDEDA WiKi

User Tools

Site Tools

Trace:
zededa:patch-envelopes

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
zededa:patch-envelopes [2026/07/23 23:12] – mczededa:patch-envelopes [2026/07/23 23:24] (current) – mc
Line 23: Line 23:
  
 ===== What can the binary artifact be? ===== ===== 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 **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   * certs, keys, a license file, a token
   * a firmware image, a tarball / zip, a small dataset, a DB seed   * 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   * 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). > 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. > 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 **How to detect changes without busy-polling:** fetch ''description.json'' and compare the
zededa/patch-envelopes.1784848334.txt.gz · Last modified: by mc