REQ: otomi validate-templates

[0-sv]

I just had a conversation with @Jehoszafat Zimnowoda about #290. @Morriz has said it could be done in 2 lines of code. This might be true, but @Jehoszafat Zimnowoda and I also came to a conclusion that the addition is a bit more nuanced and needs some extra discussion.

To avoid that we will endlessly go into the details, this is what the the implementation will look like to an end-user. We have one case right now:

otomi validate-templates
# validate everything
...
Validation Success!

From requirements setting it is inferred that we need two cases now:

otomi validate-templates -l (or --label) name=charts/someChart
# validate someChart
...
Validation Success!

and

otomi validate-templates -A (or --all) 
# validate everything
...
Validation Success!

To me it seems there are two nuances:

• Specifying parameters would require implementing some form of CLI argument parsing, @Morriz suggested https://stackoverflow.com/questions/192249/how-do-i-parse-command-line-arguments-in-bash.
• Targeting only one chart would require modification of the validate-templates function.
• I can appreciate adding unit tests, but maybe outside of the scope. I won't do it unless we've discussed it first.

Please consider my experience, I might have made mistakes in my thinking, so just let me know if this is the wrong way to go about it.

[0-sv]

Obviously I know you can just change L76 of bin/validate-templates.sh to:

hf -l name=someChartName template --skip-deps --output-dir="$k8sResourcesPath" >/dev/null

[j-zimnowoda]

Thank you for staring this discussion from a user perspective!

To be more consistent with rest of the commands:

otomi validate-templates -l (or --label) name=<release-name>

FYI: The <release-name> is a name of release defined in helmfile. We decided by convention that it should follow a chart name by that is not always the case.

To stay backward compatible, the otomi validate-templates without any parameter should validate every release for each cluster.

otomi validate-templates

There is one more use case, where you could define a specific cluster or current cluster.
Intuitively I think we should NOT implement it. In my opinion we have to validate manifests against all clusters that a given release is going to be deployed.

[Morriz]

No backwards compatibility needed here.

We wish to be explicit about validating ALL targets, so we are introducing --all flag.

[0-sv]

Thinking about it today, we seem to have 4 cases.

otomi validate-templates # error: please specify --all or --label
otomi validate-templates --label name=some-release # validate 1 manifest against all clusters
otomi validate-templates --all # validate all manifests against all clusters
otomi validate-templates --all --label name=some-release # error: can't specify all and label simultaneously 

@j-zimnowoda's suggestion was to add the following options as well:

otomi validate-templates --cluster aws-dev

I think it would be useful for development purposes. But let's come to an agreement here.

It would result in 7 cases:

otomi validate-templates # error: please specify --all or --label
otomi validate-templates --label name=some-release # validate 1 manifest against all clusters
otomi validate-templates --label name=some-release --cluster aws-dev # validate 1 manifest against all clusters
otomi validate-templates --all # validate all manifests against all clusters
otomi validate-templates --all --label name=some-release # error: can't specify all and label simultaneously
otomi validate-templates --all --cluster aws-dev # validate all manifests against aws-dev
otomi validate-templates --all --cluster aws-dev --label name=some-release # error: can't specify all and label simultaneously against aws-dev

tl;dr

• most easy: only add --label flag
• best for development: --label and --cluster

[Morriz]

That could indeed be useful IF we gain simultaneous deployments with that. Otherwise we mimic kubectl with `otomi configure` for setting target cluster

…

On 19 Feb 2021, at 14:20, Sebastiaan Verbeek ***@***.***> wrote:  Thinking about it today, we seem to have 4 cases. otomi validate-templates # error: please specify all otomi validate-templates --label name=some-release # validate 1 manifest against all clusters otomi validate-templates --all # validate all manifests against all clusters otomi validate-templates --all --label name=some-release # error: can't specify all and label simultaneously @j-zimnowoda's suggestion was to add the following options as well: otomi validate-templates --cluster aws-dev I think it would be useful for development purposes. But let's come to an agreement here. It would result in 7 cases: otomi validate-templates # error: please specify all otomi validate-templates --label name=some-release # validate 1 manifest against all clusters otomi validate-templates --label name=some-release --cluster aws-dev otomi validate-templates --all # validate all manifests against all clusters otomi validate-templates --all --label name=some-release # error: can't specify all and label simultaneously otomi validate-templates --all --cluster aws-dev # validate all manifests against aws-dev otomi validate-templates --all --cluster aws-dev --label name=some-release # error: can't specify all and label simultaneously against aws-dev tl;dr most easy: only add --label flag best for development: --label and --cluster — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[0-sv]

Do we limit it to --cluster, or also add --cloud?

E.g.:

otomi validate-templates --cloud aws --cluster dev (...)

Then it could also enable to specify all clouds or all clusters of some type.

[Morriz]

as discussed only --cluster

[0-sv]

Otherwise we mimic kubectl with otomi configure for setting target cluster

kubectl config writes the configuration back to $KUBECONFIG. Can you suggest a solution to keep state with regards to target cluster?

[Morriz]

I don't mind if it is kept in env through exported vars, as it does not need to be stateful amongst shell sessions.

[Morriz]

So we can use what we have now but add a subcommand to modify those