Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Awless: A Mighty CLI for AWS

github.com

Post reply on HN
Print view View original

21–30 of 120 posts

Re: Awless: A Mighty CLI for AWS

#21

Post by mbreese »

scaryclam wrote: post #15
hbbio wrote: post #13

Earlier quoted context omitted.

Project creator here (but obviously not the OP). Yes, we do collect minimal anonymised statistics in the sole goal of improving awless. All the statistics code is here: https://github.com/wallix/awless/blob/master/stats/stats.go As the project is Apache licensed, you're free to modify it if you don't want this. Also, if you're conscious about privacy you should use application firewalls on your client side like Littl…

I like the look of this, so on the software side it's a thumbs up. However, the fact that the code is active at all will rule it out for some companies (firewall or not). Perhaps make it something users can turn off in a config file? Not everyone can code in go, especially if their job is as a sysadmin, which isn't unlikely given that this is an infrastructure tool, so it might not be as simple as forking and editing…

Or make it turn-off-able (?) with an environmental variable. There are a couple of ways to make the tool default to report and allowable in non-reportable environments. The key thing is to make what is happening transparent.

Re: Awless: A Mighty CLI for AWS

#22

Post by spullara »

jsk2600 wrote: post #17

Sorry for off-topic question, but is this considered good golang code ? https://github.com/wallix/awless/blob/master/stats/stats.go 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 !

That is actually how you do error handling in go. Just awful IMHO.

Re: Awless: A Mighty CLI for AWS

#23

Post by edsouza »

heartsucker wrote: post #6

> 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.

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...

Re: Awless: A Mighty CLI for AWS

#24

Post by fxaguessy »

dkersten wrote: 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.

Re: Awless: A Mighty CLI for AWS

#25

Post by sly010 »

jsk2600 wrote: post #17

Sorry for off-topic question, but is this considered good golang code ? https://github.com/wallix/awless/blob/master/stats/stats.go 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 !

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 instead of the above, you often just receive a "permission error", but you don't know where it came from, which can make debugging hard.

Edit: formatting

Re: Awless: A Mighty CLI for AWS

#27

Post by ezekg »

hbbio wrote: post #13
heartsucker wrote: post #6

> 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.

Project creator here (but obviously not the OP). Yes, we do collect minimal anonymised statistics in the sole goal of improving awless. All the statistics code is here: https://github.com/wallix/awless/blob/master/stats/stats.go As the project is Apache licensed, you're free to modify it if you don't want this. Also, if you're conscious about privacy you should use application firewalls on your client side like Littl…

What does the data payload look like? I'd like to see the actual data you're sending, even if it's just a mock. From digging around in the code, it looks like you're sending infra data, including instance IDs. How do I know you aren't sending my AWS access tokens[0]?

[0]: https://github.com/wallix/awless/blob/e2bf4f2cad37b011c5b3b6...

Re: Awless: A Mighty CLI for AWS

#28

Post by matthewmacleod »

ceejayoz wrote: post #12
matthewmacleod wrote: post #9

Earlier quoted context omitted.

Instead of bitching about it, you could very simply and easily fork this entirely open-source project and remove the code. It's literally a single line-change.

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

Maybe you're right and I'm being unfair. It just seems kind of dick-ish - what's wrong with even "Cool, but I don't like stats being collected, please make this opt in"?

Re: Awless: A Mighty CLI for AWS

#29

Post by jsk2600 »

sly010 wrote: post #25
jsk2600 wrote: post #17

Sorry for off-topic question, but is this considered good golang code ? https://github.com/wallix/awless/blob/master/stats/stats.go 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 !

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 ?

Re: Awless: A Mighty CLI for AWS

#30

Post by the_duke »

hbbio wrote: post #13
heartsucker wrote: post #6

> 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.

Project creator here (but obviously not the OP). Yes, we do collect minimal anonymised statistics in the sole goal of improving awless. All the statistics code is here: https://github.com/wallix/awless/blob/master/stats/stats.go As the project is Apache licensed, you're free to modify it if you don't want this. Also, if you're conscious about privacy you should use application firewalls on your client side like Littl…

You should at least provide a prompt on first start that asks if participating in analytics collection is acceptable.
Post reply on HN