`make prepare` tries to install older Terraform

Confirming that I was able to duplicate this issue. Shoving a downloaded file's contents straight into /usr/local/bin is a BadIdea(TM) and kinda "rude" for lack of a better word.

Suggestion on logic:

Examine $PATH. Is terraform there? No? exit(1) and put download / install instructions on STDOUT/STDERR.
Yes, it's there? Check the version and use the Ruby-style soft version matching @mkb recommended. Is it < whatever our project requires? (Which begs the question: where are we going to designate - preferably as a variable - a minimum terraform version?) So yeah, not good enough? See fail path for previous step.
Oh what's that, we have a valid version? Great! Carry on. :smiley:

I strongly suggest we exercise additional caution against any thinking that may lend itself to an "auto-assumption" that all users will be executing this within the OS X development "ecosystem". Linux desktop and even Windows 10 installations with WSL are totally valid execution environments, so we shouldn't auto-assume that Mac-related tools and luminaries of OS X's OSS toolchain/ecosystem are automatically present. This is why I suggest dumping installation instructions to the screen if terraform isn't found instead of jumping to any auto-install method. (And if we want to offer opt-in automation specific to OS X, that's great as long as it doesn't auto-fire assuming everyone's rocking the pretty Apple laptop.)

Alternative approach:

Create tools/terraform as a directory in the project; include a README for explanation;
When running make prepare, check to see if, under this repo's root directory, under bin/ there's a valid terraform CLI executable (likely as a symlink). It should be sitting right next to bin/nbb for example. If there, check its version against whatever we declare is the blessed and sanctified version we'll use here.
No CLI under bin/terraform? Wrong version? Download the appropriate archive for the OS/ARCH and decompress to tools/terraform. (Also, have a known good md5 or sha hash and hash the downloaded file for safety.)
symlink tools/terraform/bin/terraform to bin/terraform.
Repeat the same aforementioned check to be sure it's there and sane.

Now, for anything where we call terraform, modify the script to explicitly look for and use the version we symlinked at bin/terraform instead of relying on $PATH. This prevents the user from needing it installed on their system at all and allows us maximum control over every single little detail of which terraform version is being used. It also prevents version conflicts with whatever the user may have installed on their system of their own volition.

Thinking about the future - this alternative approach may be better, actually...

Put yourself 3 years in the future where terraform is at a totally new place with maybe a 2.x.x release that's totally incompatible with what we're doing with 0.6.15 right now; should we complain that their installed terraform is too new? Insist on installing a three-year-old version for this ONE command, thus blowing away their existing install? Assume that it'll work the same even though the major version is far and away different signifying API-breaking changes?

Yes, I know we intend to be around and maintaining this project for the long haul, but anyone viewing this objectively and through the eyes of experience knows that no matter how good the intentions or how strong the will, no matter how great the organization, the community or the engineers, reality has a way of kicking you square in the most painful place for your gender, thus interfering, often in a big, biiiig way, with those plans. Since we can't predict the future, and since we can engineer for longevity, we should do so.

That said, dissenting opinions on the approaches herein, as well as new ideas, are wholeheartedly welcome and indeed sought.

cloudfoundry-community-attic / aws-nat-bastion-bosh-cf

`make prepare` tries to install older Terraform #32