getnelson/cli

Command Line Utility for the Nelson platform

cli's Issues

Network error handling should be improved

Currently, if the CLI fails to communicate with your Nelson server, you get a rather cryptic looking stack trace - would be better to have something that can be a bit more helpful.

Sample:

[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x134654c]

goroutine 1 [running]:
main.WhoAreYou(0xc42008a840, 0xc420110450, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/home/travis/gopath/src/github.com/Verizon/nelson-cli/src/github.com/verizon/nelson/system.go:85 +0x4dc
main.main.func19(0xc4200d8c80, 0x0, 0xc4200d8c80)
	/home/travis/gopath/src/github.com/Verizon/nelson-cli/src/github.com/verizon/nelson/main.go:755 +0x87
gopkg.in/urfave/cli%2ev1.HandleAction(0x139c880, 0xc4200c9160, 0xc4200d8c80, 0xc42006c800, 0x0)
	/home/travis/gopath/src/github.com/Verizon/nelson-cli/vendor/src/gopkg.in/urfave/cli.v1/app.go:485 +0xd4
gopkg.in/urfave/cli%2ev1.Command.Run(0x141211a, 0x7, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1420c22, 0x2b, 0x0, ...)
	/home/travis/gopath/src/github.com/Verizon/nelson-cli/vendor/src/gopkg.in/urfave/cli.v1/command.go:193 +0xb72
gopkg.in/urfave/cli%2ev1.(*App).RunAsSubcommand(0xc4200f04e0, 0xc4200d8a00, 0x0, 0x0)
	/home/travis/gopath/src/github.com/Verizon/nelson-cli/vendor/src/gopkg.in/urfave/cli.v1/app.go:374 +0xacc
gopkg.in/urfave/cli%2ev1.Command.startApp(0x1411af4, 0x6, 0x0, 0x0, 0x0, 0x0, 0x0, 0x142576b, 0x45, 0x0, ...)
	/home/travis/gopath/src/github.com/Verizon/nelson-cli/vendor/src/gopkg.in/urfave/cli.v1/command.go:280 +0x824
gopkg.in/urfave/cli%2ev1.Command.Run(0x1411af4, 0x6, 0x0, 0x0, 0x0, 0x0, 0x0, 0x142576b, 0x45, 0x0, ...)
	/home/travis/gopath/src/github.com/Verizon/nelson-cli/vendor/src/gopkg.in/urfave/cli.v1/command.go:79 +0x14c7
gopkg.in/urfave/cli%2ev1.(*App).Run(0xc4200f01a0, 0xc42000e480, 0x3, 0x3, 0x0, 0x0)
	/home/travis/gopath/src/github.com/Verizon/nelson-cli/vendor/src/gopkg.in/urfave/cli.v1/app.go:250 +0x7d0
main.main()
	/home/travis/gopath/src/github.com/Verizon/nelson-cli/src/github.com/verizon/nelson/main.go:1109 +0x458e

namespace creation uses incorrect data structure

The CLI attempts to supply a string to the create namespace endpoint, however it expects a non-empty collection.

while trying to run nelson commit, the response error message printed is empty

I ran nelson unit commit --unit unitname --version 1.0.0 --target tgt It was unable to commit. It prints on stdout Response was: but without any response or error message about why it failed to commit.

Better output when inspecting units

Often times before I do a nelson commit to promote a workload from one namespace to another I do nelson units list first, instinctively. Unfortunately nelson units list only gives the MAJOR.MINOR, whereas nelson commit of course wants MAJOR.MINOR.PATCH.

Of course we can find the full version with nelson stacks but seems kind of weird/inconsistent. Should we just make nelson units list give the full version?

CLI tool doesn't honor system DNS resolvers

At our company, we access shared environments via VPN (Cisco AnyConnect Client). The client then mangles the system's DNS resolver stack so that "internal" hostnames can be resolved properly while the user is connected to the VPN.

This method works for all std CMD line tools, such as ping, etc.

Nelson, however doesn't seem to be picking up the newly changed DNS stack.

Temporary fix: manually edit your /etc/hosts to add the needed hostname(s)

repos sync times out when syncing thousands of repos

When your github account has access to thousands of repositories on Github, it would appear that the client is timing out - the sync ultimately completes on the server, but the client bails before that happens. This is kinda a crappy user experience as the error presented is suboptimal:

λ nelson repos sync
[Post http://nelson.local:9000/v1/profile/sync: EOF]
Unable to synchronize repositories.

For some reason, the timeout is either not being honored on the client, or the server is cutting the connection but its not clear which.