[aceforeverd]

A site profile can now list presets: named chart values a deploy may pick one of.

presets:
  storage-net-pd:
    description: prefill on storage-network nodes   # optional, shown in the picker
    values:                                         # any chart values, unchecked
      tolerations: [...]
      pd:
        prefill: { affinityReplace: {...} }

swissd only parses, stores and serves them, as presets in /api/profile. The console merges the picked preset into the form layer, so compose and apply are unchanged. The profile struct needs the field because site.Parse takes known fields only: without it, a profile with presets fails to parse.

Rollout: deploy this swissd before adding presets to a site profile. An older swissd refuses the whole profile.

Console side: modelsphere/console#127 (the picker on deploy, and editing the release's affinity and tolerations on upgrade).
Refs modelsphere/modelsphere#57 (item 3, storage-network placement).

Testing

• TestPresetsRoundTrip: parses a preset, then marshals the profile and parses it again unchanged, which is the path a form-mode save takes.
• TestPresetValuesMustBeAMap: a preset whose values is a list doesn't parse.
• go test ./... passes and gofmt -l is empty.

[huskcass]

No blockers. Two-field struct plus parse tests, CI green; the round-trip test covers the form-mode save path.

Design check: nothing speculative. Preset is the minimum needed because site.Parse is known-fields-only, and swissd composes nothing from it. Nothing to cut.

Low: description is optional and values is unvalidated by design; a typo'd chart key will only surface when the console applies it. Acceptable given the stated intent.

Verdict: fine to merge. The deploy-swissd-first rollout note in the description matters.

— Review Golden