I hate to pile on to the complaints about sending usage metrics to a server, but this is pretty funky. The metrics include the instance id, account id, a list of the commands run with timestamps, the region, a bunch of metadata about the number of VPCs, Subnets, IAM users and policies, etc. Which is kind of a lot to get, and definitely isn't anonymous. Why do they need to know how many VPCs, Subnets, IAM users, and IAM roles I have?<p>Then there's how the data is sent. The metrics are converted to JSON, gzipped, then AES encrypted with a random key. The random key is then encrypted with a constant public key. the encrypted key and encrypted payload are serialized into some JSON, and is then POST-ed to an HTTPS URL. This seems unnecessarily convoluted, and even with my meager knowledge of crypto I already see some problems (compressing then encrypting is a no-no) which could spell trouble. Shouldn't you just need to upload the JSON of the metrics over an SSL connection?
> We also collect a few anonymous data (CLI errors, most frequently used commands and count of resources).<p>Looks cool, but this is an instant no for me. Sorry guys.
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.
Sorry for off-topic question, but is this considered good golang code ?
<a href="https://github.com/wallix/awless/blob/master/stats/stats.go" rel="nofollow">https://github.com/wallix/awless/blob/master/stats/stats.go</a><p>I'm considering learning go but amount of 'return err' and 'return nil, 0, err' is instant turn-off. Is this best-practice error handling in go ?
Thanks !
How about some instructions on building it ?<p>It lacks a Makefile or any documentation in the tarball for the latest release (v0.0.13)...<p>I found some sparse documentation on the wiki, but that appears to fail. I tried: GOPATH=$(pwd) go build .<p>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)
/home/rkeene/Downloads/awless-0.0.13/src/github.com/wallix/awless/commands (from $GOPATH)
If anyone is interested in a more minimalistic alternative to this, I have been designing an "as simple as possible, but no simpler" devops toolkit and CLI on top of the AWS CLI: <a href="https://github.com/kislyuk/aegea" rel="nofollow">https://github.com/kislyuk/aegea</a>
Looks great. My main complaint is that the templates feature appears to be reinventing Terraform. Would have been cool if we could use the Terraform templates we already have, or even provide support for CloudFormation (given this is an AWS-only tool).
This looks great. I use the boto tools for all my aws stuff but they're clumsy for working in an interactive fashion like this. Going to install now to have a play!
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.
Currently I'm using: <a href="https://github.com/awslabs/aws-shell" rel="nofollow">https://github.com/awslabs/aws-shell</a> and I love it
i like that RDF to sync states from between local and remote. Nice to see similar idea that I had for while to have a client for AWS that sync states between AWS and local.
How do you manage multiple environments (staging / production) with these type of tools? How do you avoid making changes in the wrong environment?
To all those complaining about collection of stats: Pretty much _every_ SaaS company is collecting stats about your behavior. It seems a bit off that there is so much rage about a project whose code is out their in the open to collect stats.<p>Point me to atleast a single popular SaaS product that does not have analytics in it's page.