Closed anonymuse closed 8 years ago
Before you run the plugin, the PATH
may not be exported properly. The plugin does only terraform apply
. There is a directory flag you should use to point to a directory like so: https://github.com/docker/infrakit/blob/master/example/instance/terraform/cattle_demo.md#2-start-the-plugins The directory is where your main.tf
and .tfstate
files live, etc.
Can you do a which terraform
and terraform -h
or show the version of Terraform? This plugin was built using the latest version, also developed on a Mac and tested on AWS.
Hi @chungers, thanks for the response.
I believe the problem lays here:
export PATH=$GOPATH/bin:$PATH
in the environment setup. Putting the GOPATH in from of the PATH, without controlling the path of Terraform, causes InfraKit to call the Terraform plugin instead of the Terraform software.
Depending on how InfraKit evolves, I'd consider solving this at the software, or the environment level. Do you plan to import the Terraform module at some point to avoid shelling out to the system?
The quickest and dirtiest solution that worked for me was to add the path to Terraform ahead of the GOPATH, which could be programmatically derived with a little command line magic (which + dirname, perhaps) in your setup script.
$ which terraform
/usr/local/bin/terraform
$ export PATH=/usr/local/bin:$GOPATH/bin:$PATH
If you thought this was the appropriate direction for the fix (as opposed to importing TF, or another solution, I could suggest an export that should work for everyone.
I ran into this too today. For me, I had my terraform from harshicorp installed in my go path. Then the terraform binary from infrakit overwrote the terraform binary from harshicorp. Seems it is best to call it terraform-plugin or others to differentiate from the terraform binary from harshicorp.
We could work around this by naming our binaries differently. Binary names like file
, vagrant
, and terraform
collide with common commands (as we see here) and should be more descriptive. Since the intent is not for humans to frequently interface with InfraKit plugins, more verbose plugin names should be fine.
@linsun just realized i basically re-stated your comment, sorry about that!
@linsun -- great suggestion.
@wfarner -- is creating verbose plugin names something you'd like us to take a pass at, or would that be best decided by the maintainers?
@anonymuse feel free to lead the charge! Tossing out my 2c, but the format infrakit-{{kind}}-{{name}}
(making this one infrakit-instance-terraform
) seems sufficiently descriptive. I'm open to other thoughts though.
Please go ahead and make a PR. Let's come up with more descriptive names for the binaries.
The only caveat is that right now the Makefile kind of cheats by using the directory names of the cmd
or examples
. Maybe introduce Makefiles for each of the binaries and that way we can recursively build all the binaries and still have the binaries be named however we want, without changing directory names, via the go build -o
options in the sub-Makefiles.
Personally, i'd prefer we stick to the single Makefile
for now.
+1 on infrakit-instance-terraform, thank you guys!!!
FYI i'm going to take on the binary renaming in https://github.com/docker/infrakit/pull/212 since any other PR would likely have numerous conflicts on the doc changes.
Hi all,
In running through the Terraform demo, I'm having trouble when I set InfraKit to start watching the group:
In window01 I launch the terraform plugin:
Once I try to set InfraKit to watch that group:
I get a bunch of errors in the original window01 that makes it seems as though InfraKit can't find the Terraform executable.
Running
terraform
outside of the directory gives me this the expected program output:While running it in the Go program directory starts the unix sock:
Unsure of how to tell if InfraKit is calling Terraform appropriately, or how to set it. This is on Mac OSX Yosemite.