argo lint requires kubeconfig

[groodt]

BUG REPORT:

What happened:
argo lint failed in my CI environment

What you expected to happen:
argo lint to succeed

How to reproduce it (as minimally and precisely as possible):
Fails:

curl --silent https://raw.githubusercontent.com/argoproj/argo/master/examples/coinflip.yaml > wf.yaml ; argo lint wf.yaml ; rm wf.yaml

Succeeds:

curl --silent https://raw.githubusercontent.com/argoproj/argo/master/examples/coinflip.yaml > wf.yaml ; argo --kubeconfig=config lint wf.yaml ; rm wf.yaml

Environment:

• Argo version:
  2.4.1
• Kubernetes version :

clientVersion:
  buildDate: "1970-01-01T00:00:01Z"
  compiler: gc
  gitCommit: 5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0
  gitTreeState: archive
  gitVersion: v1.14.3
  goVersion: go1.12.7
  major: "1"
  minor: "14"
  platform: darwin/amd64
serverVersion:
  buildDate: "2019-08-21T22:32:40Z"
  compiler: gc
  gitCommit: 5047edce664593832e9b889e447ac75ab104f527
  gitTreeState: clean
  gitVersion: v1.14.6-eks-5047ed
  goVersion: go1.12.9
  major: "1"
  minor: 14+
  platform: linux/amd64

Context:
I understand the difficulty in linting Workflows which have been decomposed into WorkflowTemplates, but I'm not sure a lint should attempt to resolve Kubernetes resources.

Perhaps an additional command that does a full validate or an option to lint to prevent it from connecting to a cluster would be more appropriate.

A lint in my opinion should purely validate the structure or schema of the individual files, not the entire graph if it happens to contain remote resources in a cluster.

[groodt]

cc @thundergolfer

[jessesuen]

@dtaniwaki is it possible to make client-side linting not require a kubeconfig in the case where templates are not used?

[dtaniwaki]

Let me try.

[thundergolfer]

Even in the case where templates are used, is it possible for lint to make network calls? That's a reason I can think of for needing KUBECONFIG but I don't think a linter should be making network calls.

[dtaniwaki]

A lint in my opinion should purely validate the structure or schema of the individual files, not the entire graph if it happens to contain remote resources in a cluster.

If I understand this comment correctly, we also shouldn't check inputs, outputs and arguments check in the lint command. Am I right? Then, I will just make another package only for linting which just checks the structure, and the validation command will use the lint and validate inputs, outputs and arguments and try to resolve workflow templates. What do you think?

[groodt]

Ultimately, it's up to @jessesuen and yourself to decide. I just found it strange that my CI lint operation started requiring a KUBECONFIG file. I think your suggestion of a different resolve or validate operation would be welcome from my perspective.

Personally, I think a lint should only have local context and not make any network requests. A linter for a dynamic language such as Python or Ruby or JavaScript isn't checking package registries for example. Their linters only check for local syntactical issues, not runtime issues.

I feel like the Argo lint operation should be similar to how kubeval works, purely against the schemas of the specs and CRDs.

I realise that Argo Workflow Templates have changed the model somewhat. They help with template verbosity and reuse, but they limit the amount of local reasoning that can be done. This is the same trade-off that other Kubernetes resources make as well though. For other kubernetes resources, you can lint specs locally, then run a different operation to see what the remote state changes will be. Hopefully people are using templating languages such as jsonnet or other to build up their Workflows and Templates, so in those cases, the links between a Workflow and any associated Workflow Templates are already handled by the templating language's import system.

Templates and Workflows can still be linted independently, just not validated that a fully composed Workflow and any remote Workflow Templates will work at runtime. For those cases, I feel like a different operation, such as what kubectl offers with it's diff or apply --dry-run operations are more suitable. Perhaps even the argo submit --dry-run operation is more suitable for this type of "deep" validation operation.

In summary, I personally would prefer the following:

• lint - Only local, syntactical checks and references. If there are remote references, they remain unchecked.
• resolve or validate or submit --dry-run or lint --deep or similar operation to perform deeper validation of Workflows and associated templates.

[thundergolfer]

There's been a regression of this I think. On Argo 2.6.1:

KUBECONFIG="" argo lint                                                                                                                                                                        
FATA[0000] invalid configuration: no configuration has been provided

[thundergolfer]

@sarabala1979 can this be reopened please? I think it's also still present on 2.8.2 (latest @ June 30 2020).