Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linting troubleshoot specs #1312

Open
banjoh opened this issue Aug 25, 2023 · 2 comments
Open

Linting troubleshoot specs #1312

banjoh opened this issue Aug 25, 2023 · 2 comments
Labels
type::feature New feature or request

Comments

@banjoh
Copy link
Member

banjoh commented Aug 25, 2023

Describe the rationale for the suggested feature.

When people craft troubleshoot specs, errors that violate the schemas can go unnoticed. We need a way to lint specs and provide meaningful feedback to users

Describe the feature

  • Create a new API to lint specs against troubleshoot schemas that returns results that can be used by clients to render results in UIs etc
  • Create a cli subcommand the uses the API above to run against input specs e.g troubleshoot lint <specs>
  • Ability to provide linting rules e.g enforce always having timeouts on certain collectors - Do we want this?. Lets leave enforcing rules to the OpenAPI schemas

Additional context

@banjoh banjoh added the type::feature New feature or request label Aug 25, 2023
@chris-sanders
Copy link
Member

Linting for validity of a spec seems useful. However, linting shouldn't be used to enforce optional parameters. Linting should only verify that it's valid input. I'm just not sure on the current priority of this. In particular would the linter only process yaml inputs or would you be able to lint a spec in a helm file?

@banjoh
Copy link
Member Author

banjoh commented Aug 29, 2023

However, linting shouldn't be used to enforce optional parameters. Linting should only verify that it's valid input.

That's correct.

Linting in this context has emphasis on how validation errors are reported so they can be consumed by clients (CLI, UIs etc)

In particular would the linter only process yaml inputs or would you be able to lint a spec in a helm file?

  • For the CLI implementation, I would have the command comform with the other CLIs. Using the helm file example, this would look like helm template <chart> | troubleshoot lint. This would extract troubleshoot specs, lint them against the version of troubleshoot schema of the binary and report errors in a fashion users will know what needs fixing

  • For the library implementation, we'd have an API that takes TroubleshootKinds as an input, which would have been loaded prior. The API would then validate the specs against the troubleshoot's OpenAPI schema and return any validation errors. Consumers of this library (including the CLIs) can use this API to report errors.

    func (kinds *TroubleshootKinds) Validate() ([]ValidationError) {
    	...
    }

Troubleshoot schemas might need to be packed with the binary. Each version of the binary is strongly dependant on a specific schema.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type::feature New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants