Live data from Hacker News

Awless: A Mighty CLI for AWS

github.com

41–50 of 120 posts

Re: Awless: A Mighty CLI for AWS

#41
post #29
post #25

Earlier quoted context omitted.

It's pretty normal and you will get used to it quickly. Thanks to this pattern it's very hard to ignore errors. The only think that could be done better is instead of always blindly returning an error, one could wrap them in higher level errors and build a sort of error trace: E.g: - task failed because - authentication failed because - could not load credentials because - because file xy.pem is not readable But inst…

Thank you ! >instead of always blindly returning an error, one could wrap them in higher level errors and build a sort of error trace Isn't that basically just reinventing exceptions, sort-of ?

Basically. It's a little different because you have more control. It's way too easy to assume exceptions won't happen and basically ignore them. But they happen in unexpected places (e.g. every time when dealing with IO).

Exceptions only contain a function call trace (stack of function calls), while a logical error trace is more like an explicit try/catch/wrap/throw around every call and could be more informative to the end user if done properly.

Re: Awless: A Mighty CLI for AWS

#42

> We also collect a few anonymous data (CLI errors, most frequently used commands and count of resources). Looks cool, but this is an instant no for me. Sorry guys.

And for some reason, this (in my eyes useless) data collection is bundled inside the version check: https://github.com/wallix/awless/blob/master/stats/stats.go#...

Not useless, gives them usage numbers.

Re: Awless: A Mighty CLI for AWS

#43
post #23

Earlier quoted context omitted.

Also upload the a hash of the userid and accountid. Hashed with non-random salt so it's not really anonymous as the function says. userid and accountid stored in database here: https://github.com/wallix/awless/blob/e2bf4f2cad37b011c5b3b6... retrieved by stats here: https://github.com/wallix/awless/blob/e2bf4f2cad37b011c5b3b6... Added to stats payload here: https://github.com/wallix/awless/blob/e2bf4f2cad37b011c5b3b6.…

(I'm one of the core developpers of awless) The hash functions are totally unrevertable, so it is impossible to come back to the original identifiers. We added these anonymous ids, in order to know which commands are the most used per users. Anyway, if you have better ideas on how to manage this, feel free to make a pull request or create a Github issue. And if you prefer to disable it, you can also do it easily with…

You can create a randomly generated cookie of sorts instead of doing anything with a users' credentials. The supposed accomplished task and end goal would be the same, and yet, people would feel more comfortable.

Your claim that you are using an irreversible hash is not comforting.

Your forced data collection is also not comforting.

Re: Awless: A Mighty CLI for AWS

#44
post #35

How about some instructions on building it ? It lacks a Makefile or any documentation in the tarball for the latest release (v0.0.13)... I found some sparse documentation on the wiki, but that appears to fail. I tried: GOPATH=$(pwd) go build . And got: $ GOPATH=$(pwd) go build . main.go:19:8: cannot find package "github.com/wallix/awless/commands" in any of: /usr/src/github.com/wallix/awless/commands (from $GOROOT) /…

The easiest way to build awless from source is to use our release script (go run release.go -tag 0.0.13). Or you can also get the full sources with `go get github.com/wallix/awless`. Then, `go build .` in `$GOPATH/src/github.com/wallix/awless/` should work.

Re: Awless: A Mighty CLI for AWS

#45
post #40
post #35

How about some instructions on building it ? It lacks a Makefile or any documentation in the tarball for the latest release (v0.0.13)... I found some sparse documentation on the wiki, but that appears to fail. I tried: GOPATH=$(pwd) go build . And got: $ GOPATH=$(pwd) go build . main.go:19:8: cannot find package "github.com/wallix/awless/commands" in any of: /usr/src/github.com/wallix/awless/commands (from $GOROOT) /…

It seems your GOPATH is not set correctly. First freshly install Go independently. Verify it is installed correctly with "go env". Then do a "go get github.com/wallix/awless", "cd $GOPATH/src/github.com/wallix/awless" and "go install". Then in the same prompt do "awless"

I downloaded the release tarball, so why would I also use "go get" to get the source I just downloaded ?

Re: Awless: A Mighty CLI for AWS

#46
Just wondering here, but why would you use this vs terraform? Given that I can define most of the stuff I need from AWS in terraform and check the state of the infra via plan command, what would be the use case for CLI? I'm actively trying to break the habit of modifying infra without first writing terraform document for it. This way I can always be sure that I have no surprises when creating a new environment.

Re: Awless: A Mighty CLI for AWS

#47

Earlier quoted context omitted.

That "bitching" is both constructive criticism and helpful to highlight here in the comments so others may take note.

Well, I think it's not constructive criticism. If there were a closed source project, then yes, it would be a very helpful highlight.

This kind of functionality is generally frowned upon in the Free Software world. For example, in Debian, it'd be treated as a bug and patched out. So I disagree; calling it out to inform others is entirely appropriate.

Re: Awless: A Mighty CLI for AWS

#49
post #5

Looks really slick. From my brief glance though it doesn't support the two things I love about the officials CLI: the filter and query facilities.

(I'm one of the core developpers of awless). We are going to add filters and queries very soon. We built awless by relying on RDF to represent the cloud resources. As a result, in addition to simple filters on the properties, we can also represent more complex queries such as "everthing inside a VPC", "the siblings of an instance", etc. Try the `awless show` command to have an insight of what we can do.

That sounds fantastic, thanks!

Re: Awless: A Mighty CLI for AWS

#50
post #48

How do you manage multiple environments (staging / production) with these type of tools? How do you avoid making changes in the wrong environment?

As of now, you can create a template to deploy an environment, and for instance create one master node (for instance a subnet) for each environment.

The missing values in the template (aka "holes" will be asked for by awless), so you can have staging and production deployments.

Note that we just released the project last Friday, and in particular have an ambitious roadmap for the templates. For instance, we could password protect accessing some nodes, and prevent wrong actions on the production env.

Post reply on HN