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.
How complicated have your terraform templates been? Because it gets pretty hairy pretty fast because not everything fits the declarative terraform model.
How about you just... not collect data from people? Or, at the very least, have it be an opt-in option? I'll probably never use this just on principle.
Yeah, this is a huge trust violation. I'm glad people caught on to it quickly. You should not be phoning home with _anything_ from a tool like this without it being 100% opt-in and with huge warnings and alerts. Even if you do it with the most care and best of intentions, a bug could easily compromise security of the people using your tool by uploading too much or the wrong information to your servers. This is not a…
This is symptomatic of the world we live in now. Some people don't even think twice about spying on their users.
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.
Terraform can't tell you about the stuff it doesn't know about.
Data sources in TF are sort of that. But I get what you mean.
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.
Terraform can't tell you about the stuff it doesn't know about.
And this is exactly what I'm trying to avoid. Terraform should know about most of the stuff.
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 ?
This does not require exceptions. A very simple implementation could involve appending the additional error to the messsage from the lower error level. As far as I understand, exceptions were invented so that error handling code will not clutter up the "happy path". They allow "exceptional condition handling" to be seggregated. But in real world applications you may need to, say, recover from an error. For example, if connection using https fails, fallback to http. This makes code using exceptions look wonky. So might as well use error codes always
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.
How complicated have your terraform templates been? Because it gets pretty hairy pretty fast because not everything fits the declarative terraform model.
I can see that templates can get complex pretty fast, but so far we manage it. Big benefit we have - a fresh start with infra about a year ago.
> compressing then encrypting is a no-no Perhaps it is just my own meager understanding of cryptography, but I didn't know of anything that would make this a bad idea. Can you explain why it is potentially a problem?
The "CRIME" exploit relied on encrypted compressed data. https://en.wikipedia.org/wiki/CRIME_(security_exploit)
It also relies on the ability of the attacker to inject their own data into the compressed content. Without that vector there's nothing special about compressed and encrypted data vs. any other encrypted data.
How about you just... not collect data from people? Or, at the very least, have it be an opt-in option? I'll probably never use this just on principle.
Yeah, this is a huge trust violation. I'm glad people caught on to it quickly. You should not be phoning home with _anything_ from a tool like this without it being 100% opt-in and with huge warnings and alerts. Even if you do it with the most care and best of intentions, a bug could easily compromise security of the people using your tool by uploading too much or the wrong information to your servers. This is not a…
(creator here)
Note that we got the feedback and disabled the collection until we do it right.
Also, it got "caught" in the first comment about that because it was clearly written in a Disclaimer section in the README.
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 !
This particular code would benefit greatly from named return values.
For example, BuildStats is defined as returning (* stats, int, error), when it could name those and just use naked returns. In buildInstancesStats, they name the return values but then repeat them again on all 3 return lines instead of just using a naked "return".
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 !