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

Running KTB with validateOnly option #165

Closed
akselh opened this issue Dec 12, 2020 · 1 comment · Fixed by #274
Closed

Running KTB with validateOnly option #165

akselh opened this issue Dec 12, 2020 · 1 comment · Fixed by #274
Labels
enhancement New feature or request runtime

Comments

@akselh
Copy link
Contributor

akselh commented Dec 12, 2020

It would be very useful to have an option to validate the topology files, and doing so without requiring a connection to the cluster. As it is now validation can only be done by using --dryRun, however this requires a connection towards the Kafka cluster which might not be possible in all cases.

One important use case is to automatically validate changes on a feature branch before PR approval. For security reasons you should not let the credentials for the KTB GitOps user (Kafka user that is) be available on an unprotected branch. So --dryRun is not even an option in this scenario.

Suggestion:
Add new option --validateOnly that only loads the topology and runs validations.

Running with this option obviously validates that the topology is valid per KTB requirements/"schema"; topology can be parsed that is. In addition users can provide their own validators with the topology.validations option.

It would however be great if KTB provided at least one validation out-of-the-box:

  • Validate that the topic configs set is valid for the available keys and values on Kafka topics
@akselh
Copy link
Contributor Author

akselh commented Dec 15, 2020

Update: After this was posted we figured out that we only need dryRun, the way we fixed it was to have a GitOps Kafka user with read-only permissions. Then dryRun on feature branch is ok.

Also with regards to other issues with comments on improvements on dryRun-logging it might be an advantage to have a connection to the cluster during dryRun.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request runtime
Projects
None yet
2 participants