equinix/metal-cli

Official Equinix Metal CLI

metal-cli's Issues

.dms darwin binary

Binary file for maOS: packet-darwin-amd64 binary links to a .dms file which does not appear to be a valid installable binary

`packet capactiy` should probably be `packet capacity`

One of the commands is wrong:

packet capactiy should probably be packet capacity

capactiy Capacities operations

Install via brew?

Can we make the packet cli available on Mac (and Linux) via homebrew? Also might want to think about Windows, where you can install via homebrew using WSL, or possibly Chocolatey.

variable organization

There are a lot of shared variables in a single directory used across many files. For example projectID is defined in packet device create file but used in packet project get. It would be nice to clean this up, potentially defining structs per command.

Feature request: add capacity API wrapper to CLI

Please consider adding commands to the packet CLI to query the various capacity APIs:
https://www.packet.com/developers/api/#capacity

packet-cli should obey XDG_CONFIG_HOME

Right now Packet by default stores configuration in ~/.packet/config. The XDG spec says:

$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

It isn't a huge, but this is considered to be less than ideal behavior these days. Also, I happen to know at least one person whose ~/ is a tmpfs, but XDG_CONFIG_HOME points to a persistent storage, and thusly any configuration files which are written to ~ are deleted on each reboot. This person isn't me.

I appreciate that the cli accepts a key and config file via options.

Go mod support

Would you accept a PR to move to using Go modules? It seems the community is shifting in that direction, and I must say, for all the hubbub, it has been a pleasant experience to use compared to other Go tools I'd used previously.

Rename "device" to "server"?

I think it's a bit unusual to call a server "device", in the UI it looks like:

When I first got the CLI I just couldn't see any command that would help me list the servers.

csv output in all commands that produce tables

What problem are you facing?

For reporting purposes, it's useful to take a data extract from the Packet
system and then import it into a spreadsheet for further analysis.

olekukonko/tablewriter#80 describes how to
use the tablewriter package to produce CSV output.

How could the Packet CLI help solve this problem?

Add a --csv or --output csv or similar option to format
tabular output as tables, with a design goal to import into
Excel or Google Sheets.

Alternatively, document how to reformat the JSON or YAML
output into tabular CSV format.

xdg app dir support

Can we have config in ~/.config/packet/ instead of polluting ~?

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Support pagination in hardware-reservation

Currently the packet-cli hardware-reservation get does not support any form of pagination. For example, to request 1000 records (instead of hard-coded limit of 10).

This can be achieved using curl:

curl -X GET --header 'Accept: application/json' \
  --header "X-Auth-Token: ${PACKET_TOKEN}" \
  "https://api.packet.net/projects/${SOURCE_PROJECT}/hardware-reservations?per_page=1000"

It would be nice if a command-line flag allowed the same.

Network Helper options

What problem are you facing?

I would like to use a single binary to handle all common tasks that are part of the Equinix Metal platform.

Configuring Bird is possible with https://github.com/packethost/network-helpers/blob/master/routers/bird/README.md, but the installation and requirements are more involved than pulling a single static go binary.

How could the Equinix Metal CLI help solve this problem?

Offer a packet bird (or packet bgp bird) command that generates the bird configuration (via metadata or API) and provides similar functionality to the helper (including persistent network device configuration).

While the network-helper recommends building the bird entrypoint.sh as a local image, the packet cli could be used to offer this image.

It appears that the network-helper includes a feature to run the image in a supervisord loop, to update the configuration. Similar features would need to be provided (built in go, perhaps - watch the endpoint, update the config and restart bird on update).

error messages duplicate and error code is still not reported

What happened?

In my last round (#70) of converting fmt.Printf errors to RunE errors I left NewCli as it was, for the most part. I now see the error messages are being duplicated.

NewCli could use a bit more refactoring, errored commands are still returning 0 as an exit code.

Additionally, error messages and help messages are output to standard output instead of standard error.

How can we reproduce it?

$ packet devices get
Error: Packet authentication token not provided. Please either set the 'PACKET_TOKEN' environment variable or create a JSON or YAML configuration file.
Usage:
  packet device get [flags]

Flags:
  -h, --help                help for get
  -i, --id string           UUID of the device
  -j, --json                JSON output
  -p, --project-id string   UUID of the project
  -y, --yaml                YAML output

Global Flags:
      --config string   Path to JSON or YAML configuration file

Execution error: Packet authentication token not provided. Please either set the 'PACKET_TOKEN' environment variable or create a JSON or YAML configuration file.

$ echo $?
0

CLI version (packet --version): dd3619b

`packet operating-systems get` does not return a list in a sorted order

What happened?

I'm trying to figure out exactly how to provision a particular operating
system, and to determine what my choices are.

packet-cli operating-systems get looks like it's the right command,
but the list is very long, and it's not sorted, and I know that only
some combination of operating systems and versions are available for
some machines.

At minimum it seems like the list should be returned in a stable, alphabetically
sorted order.

How can we reproduce it?

packet-cli operating-systems get

CLI version (packet --version): packet version 0.0.8

Packet CLI does not set an identifying User-Agent

What problem are you facing?

As users of Packet tools, API usage by these tools should be visible to Packet. We understand that this kind of information can lead to recognition and better support for specific tools. Support could come in the form of developer time on front-end or back-end aspects of the tools, addressing bugs, adding features, or improving performance.

How can packet-cli help?

All API consumers should be instrumented with an appropriate User-Agent. The UA is included in HTTP calls to the Packet API. The precise User-Agent used in each tool will differ to some degree. The expected components of a UA should include the name and version of the tool itself as well as the primary plugins and libraries contributing to the tool's operation.

For example,
https://github.com/packethost/packet-cli/blob/master/cmd/cli.go#L29 could benefit from a cli.Client.UserAgent assignment. In this case, the name and version of the CLI and the name and version of packngo should be included.

User-Agent: packet-cli/0.0.8 packngo/0.0.2

This may benefit from packngo exposing the version to consumers or exposing functions like SetUserAgent or PrependUserAgent that enhances the visibility of related tools.

packet-cli help in the absence of a token or config file

The help command requires an authentication token or config file to run, which is a challenge if you're trying to get help about this particular requirement.

Eds-MacBook-Pro:bin ed$ ./packet-cli help
Packet authentication token not provided. Please either set the 'PACKET_TOKEN' environment variable or create a JSON configuration file.

I think this actually may be the correct behavior to insist on getting a token or config file, but the message returned might also return the normal help text in addition, since generating that text doesn't require the token.

suggestion: load default project id from config file

Suggestion:

While I greatly appreciate the global --project-id flag, It would be nice if we could have a default project id specified in the config file as well.

performance of "packet-cli project get"

My account has a lot of projects (about 90).

When I ran packet-cli project get today, this took 1m18s to the first output. In fact I wasn't sure that it it was working at all and after about 15s I interrupted the output.

--userdata docs are unclear; "User data" ?

-u, --userdata string User data

likewise for custom data:

-c, --customdata string Custom data

Do these expect paths or strings?

Variable scoping is a bit concerning

The codebase surprises me in some ways. For example, I was trying to understand how userdata was handled in packet device create. I was surprised to find that things like alwaysPXE or hardwareReservationID are effectively globals in the entire code base. I guess it doesn't wind up being an issue if the code is ever only used in this CLI context where it's always just one off invocations, but it still seems like a bit of a code smell. Has this been an issue in practice? What happens when two commands share flag names?

An example, when you look at "create_volume" you have to just know that most of the variables that are populated from the CLI are defined in ... create_device.go. It would almost make more sense if all command flags were declared in a single file; and it would likely make it stick out more as a weird pattern, at least it does to me.

Project structure, globals

Usually Go applications use cmd directory in a bit different way. It should probably be cmd/packet-cli or just cmd/packet to get a good executable name.

Also, since everything is mashed together in a single directory, there's already a problem defining any new variables due to globals like https://github.com/packethost/packet-cli/blob/master/cmd/create_device.go#L31-L51.

It might make sense to remove those globals and those init functions https://github.com/packethost/packet-cli/blob/master/cmd/create_device.go#L128-L154

Minimum Go version requirement

Trying to build on a system where the system Go is a little bit older

go version go1.11.6 linux/arm64

I get this error message, with a module specifying a minimum version of Go:

cmd/root.go:90:49: undefined: "github.com/pkg/errors".As
note: module requires Go 1.13
/home/emv/go/pkg/mod/github.com/daixiang0/[email protected]/pkg/gci/gci.go:132:16: undefined: strings.ReplaceAll
note: module requires Go 1.14# github.com/securego/gosec/v2/rules
/home/emv/go/pkg/mod/github.com/securego/gosec/[email protected]/rules/tls.go:124:7: undefined: tls.VersionTLS13
note: module requires Go 1.14

It would be worth a note in the Requirements section that to build this you need an up-to-date Go.

packet completion is missing in the Windows binary

What happened?

using packet-cli in a cygwin bash Session,
packet completion bash
dont work:
root@box ~
$ packet completion -h
Error: unknown command "completion" for "packet"
Run 'packet --help' for usage.

root@box ~
$ packet completion bash
Error: unknown command "completion" for "packet"
Run 'packet --help' for usage.
root@box ~
$

CLI version (packet --version):
$ packet --version
packet version 0.0.7

`packet capacity get` output is hard to grep

What happened?

I'm trying to figure out capacity of a particular machine type (c2.large.arm)
across all data centers. It seems like I should be able to answer this query
with something like

packet capacity get --plan c2.large.arm

However, capacity doesn't take --plan. so the next step is to just do

packet capacity get | grep c2.large.arm

except that by inspection capacity draws funny boxes around the data,
and omits duplicate values in a column, making it unsuitable for grep:

emv@pinateck:~/src/github.com/packethost/packet-cli/bin $ ./packet capacity get | grep c2.large.arm 
|          | c2.large.arm  |             |
| nrt1     | c2.large.arm  | limited     |
|          | c2.large.arm  | limited     |
|          | c2.large.arm  | unavailable |
|          | c2.large.arm  | unavailable |

How can we reproduce it?

CLI version (packet --version): packet version 9ce0ac0

Missing support for various API endpoints

What problem are you facing?

As a user of the packet-cli, I have the expectation that packet-cli is the official CLI interface to the Packet CLI. I expect that all available API endpoints can be accessed through this CLI so that I can use the CLI in all forms of automation.

This CLI is lacking commands for some API endpoints. If a feature is not yet supported, I would like to have that information disclosed to avoid a search for the feature under a different name or command.

How can packet-cli help?

The implemented endpoints should have some representation in the CLI, be it as command stubs that emit Unsupported command output with an error code, a documented list of supported and unsupported endpoints, or as Github issues to implement the corresponding features.

Some API endpoints that are not represented today include:

• batches
• #177
• devices/{id}/bgp/
• devices/{id}/actions (reinstall, rescue)
• emails
• market
• license
• notifications
• ports
• spot-market-requests
• user/otp (identified as 2fa in the CLI)
• user update
• user/{id}/customdata
• userdata/validate
• verify-email

In some cases, the packngo API wrapper may be missing support for the endpoint. (TODO: link to packngo issue for this)

This epic issue may be broken out to address each missing endpoint. Link break-out issues here.

Make file has unspecified golang dependencies

packet-cli$ make install
go install -ldflags "-X main.Version=0.0.3 -X main.Build=`git rev-parse HEAD`"
main.go:27:2: cannot find package "github.com/packethost/packet-cli/cmd" in any of:
	/usr/local/Cellar/go/1.12.7/libexec/src/github.com/packethost/packet-cli/cmd (from $GOROOT)
	/Users/<user>/go/src/github.com/packethost/packet-cli/cmd (from $GOPATH)
main.go:28:2: cannot find package "github.com/spf13/cobra/doc" in any of:
	/usr/local/Cellar/go/1.12.7/libexec/src/github.com/spf13/cobra/doc (from $GOROOT)
	/Users/<user>/go/src/github.com/spf13/cobra/doc (from $GOPATH)
make: *** [install] Error 1

cli: "wide" output for "get" commands?

The current packet-cli has three output options. Either you can get a very very bare bones listing with a get command, or you can get extremely detailed output in YAML or JSON formats.

For example, device get gives you hostname and OS fields, but not IP addresses, so you have to do something like

packet-cli device get -i 0a67a9b1-a24d-4031-bd92-d5926cb264a4 -j | jq '.ip_addresses[0].address'

to figure out what address to connect to, machine by machine.

I'm not sure exactly what the output would need to look like, or what fields would be in a "wide" listing, but this is motivated by the -o wide option on kubectl which displays additional info, or even the w flag on ps which modifies output width.

Document `go get` install method

What problem are you facing?

Installing the Packet CLI by downloading a binary from Github is mildly cumbersome. The binary must then be chmod'd and moved into the correct directory. Binaries are available for many operating systems, but there are always others.

While tools such as brew (#38) can make this experience easier, this is a Go project. Go already has excellent support for installing tools through a common interface:

The following works today, given certain requirements such as go version.

GO111MODULE=on go get github.com/packethost/packet-cli

How can packet-cli help?

Instructions should be provided at https://github.com/packethost/packet-cli/blob/master/README.md#installation for installing using this generic approach.

`packet plan get` doesn't list any pricing info

IIRC the api returns pricing info about the various plans available, but this isn't included in the table or json/yaml output from the packet plan get command.

Previous PR breaks the CLI

Changes submitted here are breaking the CLI.
It does not allow users to use only environment variables, but only config files. This does not comply with the instructions https://github.com/packethost/packet-cli#authentication

Help text for "2fa receive" command is incorrect or misplaced

What problem are you facing?

I was attempting to use TOTP options from the CLI because my TOTP app was producing incorrect tokens. I first tried to retrieve a token and when the CLI returned a usage error to that command, I attempted to disable TOTP.

$ packet-cli 2fa receive
Either sms or app should be set

When I attempted to disable TOTP I received help text that should have been presented by the packet-cli 2fa receive command.

$ packet-cli 2fa disable
Error: required flag(s) "token" not set
Usage:
  packet 2fa disable [flags]

Flags:
  -a, --app            Issues otp uri for auth application
  -h, --help           help for disable
  -s, --sms            Issues SMS otp token to user's phone
  -t, --token string   Two factor authentication token

Global Flags:
      --config string   Path to JSON or YAML configuration file

Upon seeing this output, I realized the command that would work best for me was:

$ packet-cli 2fa receive -s
SMS token sent to your phone

How can packet-cli help?

The help text when missing an argument should include the full command help text, rather than receiving "Either sms or app should be set", I should have received that message along with the full argument list (as I received when I attempted to use packet-cli 2fa disable without a token).

The help text for disable seems to be reporting arguments that only make sense for receive. I would not expect to see flags like -a or -s listed for this command (descriptions are shown above), unless they have a different meaning (like, disable SMS 2fa). In this case, the argument description should match the behavior -- "disable sms" should not be described as "Issues SMS...".

Set up CI/CD pipeline

As discussed here with @jasmingacic and @jacobsmith928 , we should have a proper CI/CD pipeline.

feature request: spot prices

I have a weird little packet.sh with a hand rolled client that I can almost get rid of. One remaining functionality that I use it for is list spot prices for machines. It just dumps it as JSON, but it might be nice to have CLI support:

packet spot prices --loc "ams1" # filters by location
packet spot prices --sku "baremetal_1e" # filters to single sku
packet spot prices --sku "baremetal_1e" --loc "ams1" # both

(Maybe spot_prices? Not sure if there's other "spot" commands, maybe for spot reservations?)

build arm64 binaries in Makefile

The "make build" target should generate arm64 binaries for Linux as well as darwin and x86 binaries for Linux, to support using this cli on our c1.large.arm system.

https://github.com/StackPointCloud/packet-cli/blob/master/Makefile#L3

Include Bash autocompletion scripts

What problem are you facing?

As a user, I find auto-completion scripts help me to identify the available commands and parameters to commands. I can use tab-completion to avoid breaking out of the command I am typing to uncover simple CLI usage details, like the name, spelling, hyphenation, or existence of a particular parameter.

The Packet CLI does not include auto-completion scripts for my shell, Bash.

How can Packet help?

The CLI should include a command to generate the autocomplete scripts. This can be implemented here, taking advantage of spf-13/cobra support for the feature, described here: https://github.com/spf13/cobra/blob/master/shell_completions.md (more here https://github.com/spf13/cobra/blob/master/bash_completions.md).

Once the packet-cli completion bash (equivalent) command exists, make should incorporate this.

The current approach to triggering generators is to set specific environment variables, this experience could be improved as command-line arguments.

`packet-cli project get` has empty fields in the `members` record

Use case: for a project, given a project key, produce a list of the members of the project.

Problem: id field in the members record is blank, so packet-cli project get only returns UUIDs, not any directly useful information about the project members.

Eds-MacBook-Pro:bin ed$ ./packet-cli project get --json | jq .[].members
[
  {
    "id": "",
    "href": "/users/2e110882-4021-478b-ab3a-39e16b6ea4de"
  },
  {
    "id": "",
    "href": "/users/25ae489b-b566-44e3-8c6a-0c5a0ef8454b"
  },
  {
    "id": "",
    "href": "/users/738a9dd6-1872-4f43-ba3b-d223740594da"
  }
]

when I try to look up users one at a time, I get this

Eds-MacBook-Pro:bin ed$ ./packet-cli user  get -i 2e110882-4021-478b-ab3a-39e16b6ea4de
Client error: GET https://api.packet.net/users: 403 Access denied for the current authentication token 

yaml config file not autodetected

Following the readme suggests one could use either yaml or json config file and it should be detected by default. This is not the case (only the JSON file will be detected).

I'm happy to PR to autodetect the yaml file in the indicated location ($HOME/.packet-cli.yaml) if that would be accepted?

packet-cli --version returns a version of "DefaultVersion+DefaultBuild"

I'm using the binaries for v0.0.5 for linux-amd64.

packet-cli --version
packet version DefaultVersion+DefaultBuild

Looking at your Makefile, it appears the build information is being added here: https://github.com/packethost/packet-cli/blob/master/Makefile#L14

Since these variables are set earlier in the Makefile, my guess is that perhaps the release build was performed a different way?

Packet Uniform Standards Request: Maintained

What problem are you facing?

Packet maintains a number of public repositories that help customers to run various workloads on Packet. These repositories are in various states of completeness and quality, and being public, developers often find them and start using them. This creates problems:

• Developers using low-quality repositories may infer that Packet generally provides a low quality experience.
• Many of our repositories are put online with no formal communication with, or training for, customer success. This leads to a below average support experience when things do go wrong.
• We spend a huge amount of time supporting users through various channels when with better upfront planning, documentation and testing much of this support work could be eliminated.

To that end, we propose three tiers of repositories: Private, Experimental, and Maintained.

As a resource and example of a maintained repository, we've created https://github.com/packethost/standards. This is also where you can file any requests for assistance or modification of scope.

The Goal

Our repositories should be the example from which adjacent, competing, projects look for inspiration.

Each repository should not look entirely different from other repositories in the ecosystem, having a different layout, a different testing model, or a different logging model, for example, without reason or recommendation from the subject matter experts from the community.

We should share our improvements with each ecosystem while seeking and respecting the feedback of these communities.

Whether or not strict guidelines have been provided for the project type, our repositories should ensure that the same components are offered across the board. How these components are provided may vary, based on the conventions of the project type. GitHub provides general guidance on this which they have integrated into their user experience.

How could the Packet CLI help solve this problem?

We believe this repository is Maintained and therefore needs the following files updated:

• Flagged Public
• The Maintained badge
• The Maintained Statement in the README.md
• Getting Started Tutorial
• README.md
• LICENSE
• CI/CD
• OWNERS.md
• Developer Certificate of Origin
• At least two maintainers
• A Manifest File, if relevant
• Code of Conduct
• How to Contribute
• SUPPORT.md
• RELEASE.md

If you feel the repository should be experimental or end of life or that you'll need assistance to update these files, please let us know by filing an issue with https://github.com/packethost/standards.

Add a snap installation option

Snap is a powerful and simple way of installing the applications on Linux.

It would be great to have the ability to install the packet-cli tool with a single-line command as:

sudo snap install packet-cli

PS. Doing this with the Go applications is pretty straightforward - https://snapcraft.io/docs/go-applications.

CLI does not exit with an error in certain cases

I am using the packet CLI in a test, for example:

https://github.com/packet-labs/packet-multiarch-k8s-terraform/blob/master/.drone.yml#L68

where I am creating, and then attempting to delete a keypair. The way I'm identifying the key ID isn't happening correctly, so this last step should (because it's a bad/malformed argument value) be failing, but seems to exit silently (and exits 0 or else the test would fail, which it hasn't). So the argument format matches, but doesn't give a valid value for that argument, in this case.

This is easy enough to handle on my end, but the output for most of these operations seems to exit silently if it doesn't trigger the help prompts, so I figured it was worth reporting.

Offer a way to set defaults using the config file

What problem are you facing?

I often reuse the same settings when creating new resources using the Packet CLI. I must provide these settings on each invocation of packet-cli.

How can packet-cli help?

Common settings should be configurable per command, while high-level, commonly reused parameters, can be set globally. For example, in ~/.packet-cli.json:

{
  "token": "foo",
  "project-id": "some-project",
  "organization-id": "some-organization",
  "device": {
    "plan": "some-default-plan",
    "facility": "some-default-facility",
    "operating-system": "some-os",
  }
}

These parameters would coordinate with those made available through the CLI.

packet device create --hostname [hostname] --plan [plan] --facility [facility_code] --operating-system [operating_system] --project-id [project_UUID]

Parameters like facility may need more careful handling. Should they be global or command-specific? Should all parameters trickle down from global to command specific structures (Global facility is an option, but device-specific facility takes priority)?

Any form of default setting must be careful not to quash a user's ability to not specify an argument (default project-id should not affect a command that behaves differently if a project-id was not provided).

It would also be helpful to show the default values when displaying the help text, if possible.

Commands are inconsistent about plural or singular names

It is difficult to build muscle memory and intuition about the Packet CLI commands become some commands are plural (facilities, operating-systems, payment-methods) while others are singular (plan, project, device).

SPF13 supports aliases. Aliases should be added to make plural or singular alternatives for each command.

Aliases can also be used to provide short names for commands like "virtual-network" (vlan), "operating-systems" (os), and perhaps others.

allow users to specify projects, devices by name instead of ID

This is a quality of life/ergonomics improvement for developers. Passing GUIDs is generally not fun or easy from a human standpoint. People generally prefer working with recognizable, memorable strings.

I propose we hide this complexity from users. If the input provided by the user looks like a GUID, CLI should attempt to use it as such. If the input is otherwise a freeform string, the CLI should perform the necessary backend calls to correlate the name to the given project/device in the user account, and still return the correct result (as opposed to 404 in current behavior).

Happy to PR, wanted to open an issue to discuss if this is desirable first.

Support for plurals

What problem are you facing?

I never get the right command at first. Because I use projects, or devices and not project and device

How could the Equinix Metal CLI help solve this problem?

should we add support for plurals?

`packet-cli project get` returns only 10 projects in an organization that has 40+ projects

If you have an organization with many projects, the packet-cli project get command only returns the first 10.

(I think this is a case of being tripped up by the pager.)

My preference would be to always return all of the projects in the organization, rather than force the user to explicitly navigate the pager.

Repeat by: test on the "Works on Arm" project with an API key scoped to the organization. Or create 11 projects in a new organization.

SOS options

What problem are you facing?

I have to use the Equinix Metal portal to access the SOS URL to view the device console.

How could the Equinix Metal CLI help solve this problem?

I would like the following options to simplify my workflow:

• packet device create --sos would create the device and immediately SOS into the device so I can watch the provisioning happen
• packet device sos --id=$DEVICE_ID would SOS into an existing device

--termination-time rejects values that the API accepts

As I'm trying to adopt packet-cli over my pile of shell scripts, I've noticed that the termination_time I was calculating and passing directly to the API is rejected by the CLI. This seems unfortunate, to me.

It would be nice if the same values could be passed to the CLI. Better yet, if you could pass things like --termination-time="+2 hours" would be very cool as well, since this is what I'm doing anyway:

# should work, but doesn't:
termtime="$(TZ=UTC date --date="2 hour" --iso-8601=seconds)"
packet device create --termination-time="${termtime}" ...

# maybe in the future?
packet device create --termination-time="+2 hours"

IP get panics

$ packet-cli ip get -p $PACKET_PROJECT_ID
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x14505ec]

goroutine 1 [running]:
github.com/packethost/packet-cli/cmd.glob..func33(0x194e440, 0xc00000f1e0, 0x0, 0x2)
        /Users/gianarb/git/packet-cli/cmd/retrieve_ip.go:65 +0xa3c
github.com/spf13/cobra.(*Command).execute(0x194e440, 0xc00000f180, 0x2, 0x2, 0x194e440, 0xc00000f180)
        /Users/gianarb/go/pkg/mod/github.com/spf13/[email protected]/command.go:766 +0x29d
github.com/spf13/cobra.(*Command).ExecuteC(0x194fc00, 0xa, 0x0, 0x0)
        /Users/gianarb/go/pkg/mod/github.com/spf13/[email protected]/command.go:852 +0x2ea
github.com/spf13/cobra.(*Command).Execute(...)
        /Users/gianarb/go/pkg/mod/github.com/spf13/[email protected]/command.go:800
github.com/packethost/packet-cli/cmd.NewCli(0x4)
        /Users/gianarb/git/packet-cli/cmd/cli.go:34 +0x157
main.main()
        /Users/gianarb/git/packet-cli/main.go:32 +0x26

Packet CLI does not include "man" pages

What problem are you facing?

As a user, I find man pages help me to identify the available commands and parameters to commands. I can use man packet-cli to understand the features and details of CLI commands and their arguments. Additionally, manual pages are strong recommendations in some packaging environments (deb, rpm) and improve the user experience.

The Packet CLI does not include man pages on install. While docs are included, man pages are a more appropriate interface to discovering commands and arguments.

How can packet-cli help?

The CLI should include a command to generate the man pages. This can be implemented here, taking advantage of spf-13/cobra support for the feature, described here: https://github.com/spf13/cobra/blob/master/doc/man_docs.md.

Once a command to generate man pages exists, make should incorporate this.

The current approach to triggering generators is to set specific environment variables, this experience could be improved as command-line arguments.

Similar to #56