Closed portertech closed 7 years ago
There's these two packages I have noticed in the past: https://github.com/urfave/cli https://github.com/spf13/cobra (with https://github.com/spf13/viper?)
We can look to Heroku CLI for some inspiration https://devcenter.heroku.com/articles/heroku-cli
Heroku CLI is such a franken-mess of node and Go. Some of the prompts are written in Go and use libraries like https://github.com/dickeyxxx/speakeasy. Other commands are written in node and use libraries like commander and inquirer.
Outside of how it operates probably not much worth stealing code-wise.
@jamesdphillips @amdprophet added this to the "Monitorama" milestone https://github.com/sensu/sensu-go/milestone/1, MVP needs to be able to create a handler, check, and list events (e.g. sensu-cli list events).
@portertech should we be doing any verification to ensure a handler, filter, mutator, etc. exist first before a check is created?
Are we set on using sensu-cli create check
versus sensu-cli check create
? I think the latter is the pattern used by most tools and makes grouping code easier.
Not set, it just felt natural to write. We can do a quick poll (reactions):
:tada: for sensu-cli create check
:heart: for sensu-cli check create
sensu-cli check create
also allows for things like sensu-cli check bulk delete
So, the sensu-cli <primitive> <action>
syntax feels like the "right" (or at least "standard") way to do it, but I've never found this to be particularly intuitive. Could/should there be a completely different option which just uses descriptive double-dash commands (e.g. sensu-cli --create-check
and sensu-cli --modify-check
and sensu-cli --bulk-delete-check
)?
Heroku does heroku [service]:[action]
eg. heroku apps:create
heroku pg:copy
, etc.
AWS CLI is similar with aws [service] [action]
aws s3 copy
, etc.
The :heart:s have spoken.
Getting ahead of myself but the way docker organizes all it's commands and and subcommands is pretty nice 👌
https://github.com/docker/cli/blob/master/cmd/docker/docker.go#L24-L74 https://github.com/docker/cli/tree/master/cli/command/commands https://github.com/docker/cli/blob/master/cli/command/commands/commands.go
what does output look like?
sensu-cli events -o
configuration
~/.config/sensu
~/.config/sensu/credentials
~/.config/sensu/profiles
~/.config/sensu/defaults
~/.config/sensu/profiles
?Got excited about the interactive part so I did a bit of hacking last night. Most of the heavy lifting courtesy of Survey.
...configured values become the defaults.
... Viper gives us configuration from ENV variables for (mostly) free 🎉
Wow, this looks outstanding!
@jamesdphillips -- I know that viper is a little kitchen sink, but i'd rather the kitchen sink (assuming it also pulls in vendor deps that are also of acceptable licenses) than building our own configuration stuff. Also, viper has a feature that i really like.
Viper allows us to simultaneously support cli flags/args, confit files, remote kv stores (including etcd out of the box), and environment variables with precedence. That's a really powerful tool to have in the box, because configuring things a single way is annoying. You may want env cars for kubernetes pods with an etcd override for some tunables via the UI/API or feature flags, etc. You may want cli args for running on your laptop. You might want to support reading a legacy Sensu configuration json and convert the resulting go struct into an accepted configuration programmatically.
Basically, there are a bunch of ways to configure things and it turns out that viper supports all of them and provides a reasonable interface to cobra that lets us leverage the two together.
Good points. I think Viper makes a ton of sense for the the daemons in particular, nor had I even considered the legacy Sensu configuration.
yeah i think if the surface of the agent configuration is really light, in retrospect of that last comment, i guess im okay with a simplified configuration interface of: read file or parse args. oh and i think cobra supports configuration files out of the box now that i think about it. actually if you can figure out what configuration features are available with cobra--and obviate the need for viper i'm okay with that.
The Sensu CLI needs to "modes" of operation:
Raw examples (ideas):
The CLI tool will eventually need to handle authentication and authorization. For now we can no-op.