zededa:projects:deployment_type
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| zededa:projects:deployment_type [2026/08/11 12:20] – mc | zededa:projects:deployment_type [2026/08/11 12:37] (current) – mc | ||
|---|---|---|---|
| Line 51: | Line 51: | ||
| The network does not exist until a node qualifies, so the app cannot refer to it | The network does not exist until a node qualifies, so the app cannot refer to it | ||
| by name. It finds it by tag instead. | by name. It finds it by tag instead. | ||
| + | |||
| + | ==== The two words that trip people up ==== | ||
| + | |||
| + | **Target condition.** A filter written on the //policy//, not on the node. It | ||
| + | says: "only apply me to nodes whose tags include this exact key and value." | ||
| + | policy states what it is looking for, the node carries the labels, and the | ||
| + | controller does the matching. A policy with no target condition applies to every | ||
| + | node that reaches the deployment. | ||
| + | |||
| + | **netinsttag.** The same idea one level down, and about networks instead of | ||
| + | nodes. It is written on the app's network interface and says: "plug me into | ||
| + | whichever network instance carries this tag." | ||
| + | |||
| + | Why not just name the network? Because it does not exist yet. The network is | ||
| + | created by a policy at the moment a node qualifies, and it is created separately | ||
| + | for every node. There is no name to refer to when you are writing the config, so | ||
| + | a label is the only stable handle. | ||
| + | |||
| + | That is the pattern behind both: an object describes what it is looking for, and | ||
| + | the controller finds the match when the node shows up. Nothing is wired by name. | ||
| **Tip:** matches 2 and 3 both use the key '' | **Tip:** matches 2 and 3 both use the key '' | ||
zededa/projects/deployment_type.txt · Last modified: by mc
