Why would you give a Helm chart hook a negative helm.sh/hook-weight?

### Zero is a default, not a starting line Helm sorts a hook event's manifests by their `helm.sh/hook-weight` values, ascending, and treats a manifest with no such annotation as weight 0. It offers no `first`, no `last`, and no notion of a lowest legal weight. That combination has a consequence people miss: 0 is the *middle* of the scale and it is where everything unannotated piles up. If you want to be genuinely first, the only expression of that is a number below 0. ### The case that makes it necessary: hooks you do not own Inside a chart you control, negatives are a convenience - you could renumber everything to `0`, `10`, `20` instead. The case where a negative weight is the *only* answer is a chart with dependencies. Hooks contributed by enabled subcharts are flattened into the release and sorted into the same pool for the event they fire on. If a dependency ships a `pre-install` Job with no weight annotation, it is at 0, and you cannot change that - you do not own the subchart's templates, and a subchart's annotations are not something a parent's values can generally rewrite. Your options are to negotiate a change upstream, fork the dependency, or put your own hook at `"-10"` and be certain it runs first. The last option is a two-character edit in your own chart. The same holds in reverse for a chart intended for other people to depend on. If your chart's hooks all sit at 0, every consumer who needs to run something before them has to go negative. Publishing your hooks at deliberate, spaced weights - and documenting them in the chart's README - is a courtesy to consumers, and it is one of the few places where an annotation choice is really an interface decision. ### Spacing, not sequence The second reason to reach below zero is room. A chart that numbers its hooks `0`, `1`, `2` has to renumber to insert anything between the first two, and a hurried author who cannot be bothered will just duplicate a weight and recreate a tie. Numbering `-20`, `-10`, `0`, `10`, `20` leaves nine free slots on each side of every hook. Since the numbers are purely relative - only their order matters, never their magnitude - the gaps cost nothing. ```yaml annotations: "helm.sh/hook": pre-install "helm.sh/hook-weight": "-20" # ahead of anything unannotated, ours or a dependency's ``` Remember the value is a quoted string. `helm.sh/hook-weight: -20` unquoted is a YAML integer, and an annotation value must be a string, so the object is rejected when Helm applies it - a mistake that survives rendering and only fails in the cluster. ### What a negative weight does not buy you It does not move the hook out of its phase. A `pre-install` hook at `"-500"` is still a `pre-install` hook: it runs in that phase, after the release record exists and before the chart's ordinary manifests are applied, and no weight reaches earlier than the phase itself. It does not run before hooks on a different event either, because different events are different phases with their own pools. And it does not create a dependency: Helm will run the negative-weighted hook first, but nothing about the annotation says the later hook requires it - the only linkage is that a failed hook aborts the operation, so the rest of the phase never runs. ### The honest scope of this question Nobody is turned down for not knowing that weights can be negative; the mechanism is a one-line fact and the ordering it produces is obvious once stated. What separates a good answer is the reason: naming the unannotated-subchart-hook problem shows the candidate has run a chart with real dependencies and has hit the case where their own numbering was not enough. That is the differentiator, not the minus sign.