model-serving: the cache claim carries its tier so its price survives its StorageClass #605

Problem

The model cache claim (modelServing.cache.pvc) outlives the connectivity release by design (helm.sh/resource-policy: keep, applied by a hook), but its StorageClass does not: the class is Helm-owned, named by a digest of its parameters, and goes with an uninstall or with an upgrade that changes the parameters (a new digest renders a new class, the old one is removed). A bound volume works on without its class — but the class was the only place the volume's tier (type, IOPS, throughput) could be read from. cluster-manager 0.17 prices a claim from its capacity and tier (giantswarm/cluster-manager#83); with the class gone it answers "no price: the volume's tier is not known" rather than a storage-only figure, and the portal's Model cache card shows a claim that costs money without a figure. On an installation the kept claim's class had gone with a platform upgrade the same day.

Proposed solution

The hook that applies the claim stamps the tier it was provisioned with onto the claim, so the figure survives the class: annotations on the claim — the volume type, IOPS and throughput of the class the claim binds on (the chart's own parameters when it renders the class, else what the named class carries at apply time) — written once at create and left alone afterwards (a claim keeps its class and its volume's tier whatever a later release renders). cluster-manager reads the tier from the class where it exists and from the annotations where it does not, saying which.

Acceptance criteria

• modelServing.cache.pvc applied by the hook carries its tier as annotations (type, iops, throughput) at create; an existing claim without them is stamped from its class where the class still exists.
• Removing or renaming the StorageClass leaves the annotations, and cluster-manager's list_clusters still prices the claim (naming the annotations as the source).
• Chart test covers the stamped claim.