boundary
boundary copied to clipboard
boundary validate
Is your feature request related to a problem? Please describe. Need a way to validate hcl configurations on boundary before writing them.
Describe the solution you'd like consul validate or packer validate are great examples of what i am looking for. https://www.packer.io/docs/commands/validate https://www.consul.io/commands/validate
Describe alternatives you've considered None other than eye balling or trial and error.
Explain any additional use-cases Need this most certainly for HCP Boundary related use cases. This will go a long way in making the product more enterprise ready. PKI configurations like the ones described here will need to be validated prior to use. https://learn.hashicorp.com/tutorials/boundary/hcp-manage-workers#write-the-pki-worker-config
Additional context https://www.packer.io/docs/commands/validate https://www.consul.io/commands/validate https://learn.hashicorp.com/tutorials/boundary/hcp-manage-workers#write-the-pki-worker-config
Here is an error i received that could have been caught prior to starting the boundary worker if there were a validate option -
ubuntu@ip-10-66-79-132:~$ boundary server -config="/home/ubuntu/boundary/pki-worker.hcl"
{"@level":"error","@message":"event.WriteError: no eventer available to write error: Tag value "consul-PKI-worker" for tag key "type" is not all lower-case letters","@timestamp":"2022-08-15T21:52:54.849624Z"}
ubuntu@ip-10-66-79-132:~$
@ramramhariram thank you for this excellent suggestion! I can see how this functionality would be immensely beneficial to Boundary OSS as well as to users looking to deploy a self-managed worker with HCP Boundary.
I will leave this request open to solicit feedback and to gauge interest from the community via upvotes.
@ramramhariram You didn't indicate which version of Boundary you are using but this is a start-time error for me. I suspect that you have a version mismatch between your controller and worker such that the controller is newer and gave an API error, but your local Boundary version for the worker did not yet have this check which is why it got to the controller in the first place.
Generally speaking any invalid configuration should result in a start-time error; if not we should fix that as a bug.