-
Notifications
You must be signed in to change notification settings - Fork 316
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
Expose configuration information via CLI #2774
Comments
I think the thing to build here is a command that shows what the configuration would be given a ring state. What if you could say: $ hab butterfly dump ID | hab service --bind database:thing.prod debug And you get a print out of all your hooks and configuration, optionally to a directory, that you can inspect. It would mean adding a bit of protocol work to fetch the dump, but it would make debugging your services against an active ring amazing, and we could make the output of dump be just the stream of raw bytes in the dat file. |
Another useful item would be
Basically something easy you can run that prints a green checkmark if butterfly is connected and working, so you know to move on to troubleshooting the service itself. |
@christophermaier Is this linked to #2551 ? Or is this something else entirely? |
@rsertelon I think they're related in intent, though what's described in this issue sounds like a bigger, more encompassing vision of #2551 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you. |
As a Habitat user, I would like an easier way to access current configuration information for service groups.
The currently-gossipped config is available via curl, but it's cumbersome to remember the right URL. Additionally, configuration from
default.toml
anduser.toml
is not reflected in this output.Though all this information can be found today by knowing the right file paths and HTTP endpoints, having all this information easily accessible via the CLI would make debugging configuration issues much easier.
The text was updated successfully, but these errors were encountered: