Kubernetes VSCode extension resource schema validation

[StarpTech]

Describe the problem/challenge you have
Working with comments has its drawbacks. The Kubernetes extension for vscode marks all YAML values with only #@ as invalid.

Incorrect type. Expected "integer".yaml-schema: kubernetes://schema/apps/v1%40deployment

Describe the solution you'd like

• Ship a custom vscode extension
• Improve Kubernetes extension to understand ytt comments.

---

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

[pivotaljohn]

At first blush, I see this as in the impedance mismatch of interpreting a template as a document. A problem I believe would be categorically solved with #217.

That is, ytt templates are a kind of "expression" that when evaluated results in a target document. It helps me to consider flow control type directives (for loops, if statements, functions that return YAML fragments, etc.) to see things this way.

Because of this, any sort of linting over the expression will probably yield false negatives (at best) and perhaps get "confused".

But if the value being linted is the evaluated template using reasonable values (e.g. schema defaults, when scheme GAs), the results are far more useful (and will result in far fewer errors).

[pivotaljohn]

This issue outlines a clear gap in the developer UX. This is something we definitely want to improve. ==> "carvel accepted"

[pivotaljohn]

Given that LSP implementations are not trivial (and it's not actually entirely clear that it would work well with other extensions), there may be a way to at least improve the experience within vscode (or other major editor) in some other way. For this reason labeled for "discussion"

Also, we may be able to identify increments of improvement. For example, it might be possible to approach "teaching" editors ytt syntax in layers:

• supporting only same-line expressions (as described, above)
• supporting flow control statements
• supporting functions defined in the same module (i.e. file)
• supporting functions defined in a separate module (i.e. load()ed in)
• ...

Bottom-line: one or more approaches needs to be researched to be able to identify potential layers of scope in order to get to "ready for dev".

[pivotaljohn]

@StarpTech, I meant to include this in the original reply to this issue: thank you. 🙏🏻 We really appreciate you pointing out (with screen shots) where there's a bad experience. 👍🏻

[cari-lynn]

Thank you for bringing this to our attention, we do have a custom VSCode plugin, but it doesn't solve the problem you described. We do want to improve this experience however, and are always taking contributions.

[cppforlife]

would be nice to do a PR to https://github.com/Azure/vscode-kubernetes-tools to not consider it as error.

[cppforlife]

Incorrect type. Expected "integer".yaml-schema: kubernetes://schema/apps/v1%40deployment

ahhh. that's interesting. the error is actually not about the comment -- take a closer look at the squiggly. it's saying that replicas value is null and it should be an integer (according to k8s schema). hmm this is a tougher problem to solve since you are effectively deciding not to provide a value.