Replies: 4 comments 6 replies
-
|
Awesomely thorough. Great. About the repos out of date: please understand that you need to use the flag
its not
Helm specs? That makes no sense. The k8s resources have schemas and the linter just checks for deprecations and warns about them. Or throws an error even. IMPORTANT NOTE: Static analysis might differ from what the k8s api approves.
What is "it"? Where is the time going? What command is that again?
When a template is invalid (meaning it should not be accepted by the k8s api) that should be caught by
That is what we have now:
Separate issues indeed. Targeting one chart alleviates pain already.
Indeed. Warnings are ok, they suggest work is coming up when an upgrade is wanted. |
Beta Was this translation helpful? Give feedback.
-
True, it is because with helm3 you need to build the chart in order to create dependencies. |
Beta Was this translation helpful? Give feedback.
-
|
That is not an accurate depiction. We use dependencies in charts of course, we just don't want to fetch them from the internet, as we packaged everything locally already. |
Beta Was this translation helpful? Give feedback.
-
|
The point is that dependencies are always mandatory even if in values you explicitly indicate that you are not going to use that dependency. Quite accurate it think :P |
Beta Was this translation helpful? Give feedback.
-
|
If your concern is about dependencies, we can just remove them in our code if we don't use them, right? |
Beta Was this translation helpful? Give feedback.
-
|
So what is the outcome of this Discussion ? |
Beta Was this translation helpful? Give feedback.
-
|
I don't think this has an outcome/follow-up yet... It's just a report so I don't think there should be a definitive answer for it. For me personally, it's good reference material. |
Beta Was this translation helpful? Give feedback.
-
|
There should some outcome (conclusions) from the discussion, otherwise it will be never ending story that is taking people attention and does not provide actionable results. |
Beta Was this translation helpful? Give feedback.
-
|
I agree, but I thought (one of) the original premise(s) of Discussions was long-lived background info. Apologies if it's taking up attention. Of course, I am the original poster, but I don't think I am the only one that is able to make things actionable... If you feel like we have to move into a direction, I am not against taking some initiative. |
Beta Was this translation helpful? Give feedback.
-
|
It is clear now:
Locking this discussion |
Beta Was this translation helpful? Give feedback.
-
We had a conversation last week about comparing the two commands mentioned in the title,
helm(file) lintvsotomi validate-templates. Here is the report I said I would create.helm lintI think it's quite a convenient command, because it already has in-built targeting of separate charts. However, it still seems like work-in-progress (helm/helm#8596, helm/helm#6215, helm/helm#6258, helm/helm#2033, helm/helm#3880)
Whether this is useful output is open for discussion below.
helmfile lintWhere it gets interesting is the charts it is throwing an error, running it on the master repo it will exit on
istio-operator,prometheus-operatorandweave-scope. I had to performhelmfile lintin the Otomi Docker obviously, so just seeotomi lintas equivalent tohelmfile lint.Basically going through all the
helmfiles, it is throwing here forweave-scopebecause I resolvedistio-operatorandprometheus-operator.Reproduction of
charts/istio-operatorerrorHad to add quotes to its
chart.yaml:Reproduction of
charts/prometheus-operatorerrorHere it seems
helm lintis more lenient thanhelmfile lint, becausehelmfile lintwill exit upon error and it looks like helm didn't catch it, even though I have the same versions available:helm version version.BuildInfo{Version:"v3.5.0", GitCommit:"32c22239423b3b4ba6706d450bd044baffdcf9e6", GitTreeState:"dirty", GoVersion:"go1.15.6"} sebastiaanverbeek@mbprosv ~/Projects/redkubes/dev/otomi-core svatwork/task/290/hf-lint-output-discussion ± otomi x helm version version.BuildInfo{Version:"v3.5.0", GitCommit:"32c22239423b3b4ba6706d450bd044baffdcf9e6", GitTreeState:"clean", GoVersion:"go1.15.6"}Here's the output of
helmfile lint, it looks like it does a repo update besides linting and then throws:The problem is that the repository of the dependency is not actual anymore in
Helm 3.Old:
New:
This will pass.
otomi validate-templates
tl;dr
otomi validate-templatesvalidates against Kubernetes v1.18 for all clusters. Whereashelm lintandhelmfile lintmight just lint against Helm specs and yaml in general.otomi validate-templatesdoesn't seem to catch a lot of the yaml spec, only for Drone, and it doesn't throw an error if it finds something. That can be both good and bad: at least we have under control whether to throw an error, as it was a problem with upstream Helm on some issue in a v3.4.x version, but maybe it should throw an error and let the host/CI runner know.Moving forward
I would propose the following (open for discussion of course):
otomi lintcommand, make it part of the CIBeta Was this translation helpful? Give feedback.
All reactions