Open shydefoo opened 3 months ago
So the root cause is a difference in how Helm directly merges vs how we are merging with the 'defaults' stuff.
I think basically caused by this line: https://github.com/helm/helm/blob/847369c184d93fc4d36e9ec86a388b60331ab37a/pkg/chartutil/coalesce.go#L225.
We could solve this one-off by allowing it in the schema:
diff --git a/manifests/charts/gateway/values.schema.json b/manifests/charts/gateway/values.schema.json
index c97d84c1e5..4c4f0836d7 100644
--- a/manifests/charts/gateway/values.schema.json
+++ b/manifests/charts/gateway/values.schema.json
@@ -99,10 +99,10 @@
"type": "object",
"properties": {
"cpu": {
- "type": "string"
+ "type": ["string", "null"]
},
"memory": {
- "type": "string"
+ "type": ["string", "null"]
}
}
},
@@ -110,10 +110,10 @@
"type": "object",
"properties": {
"cpu": {
- "type": "string"
+ "type": ["string", "null"]
},
"memory": {
- "type": "string"
+ "type": ["string", "null"]
}
}
}
but that is not very general
Sflr @howardjohn and thanks for the information provided! Would it be possible to allow it in the schema? Since this would allow unsetting the default cpu limits specified in values.yaml
It should also allow integer
for the CPU. I'll try to open a PR in the next few days.
@howardjohn I'm not sure what you mean with
So the root cause is a difference in how Helm directly merges vs how we are merging with the 'defaults' stuff.
can you elaborate please?
Another resolution would be to not set resources by default, which is what most charts tend to do since no chart author can know the resource needs in a specific deployment.
can you elaborate please?
We do merging in our chart with mergeOverwrite
. It behaves differently from how helm internally merges
Is this the right place to submit this?
Bug Description
On previous versions of istio (before v1.21.0), this configuration had no issues:
However, on v1.21.0, passing this additional values file throws this error:
Upon inspecting the helm chart, it seems that a new
defaults
field is introduced, and fields underdefaults
get overwritten by the top level fields of the same name. The workaround seems to be to overwrite the fields underdefaults
, ie:Is there a way to unset the cpu field without having to move
resources
underdefaults
?Version
Additional Information
No response