You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Zordrak opened this issue
Jul 28, 2020
· 1 comment
· Fixed by #25692
Assignees
Labels
bugcoreexplaineda Terraform Core team member has described the root cause of this issue in codev0.13Issues (primarily bugs) reported against v0.13 releases
If you are providing a custom provider plugin binary via the terraform.d directory in a root module, you get different behaviour depending on whether the plugins directory inside terraform.d is a symlink.
If it is not a symlink, the new style directory emulating a registry works as normal.
If it is a symlink, then the new style directory seems to be ignored.
In either case you get write(2, "2020/07/28 18:02:18 [DEBUG] will search for provider plugins in terraform.d/plugins\n", 84) = 84
In either case the old style path of terraform.d/plugins/linux_amd64/terraform-provider-shell is enumerated, going so far as: newfstatat(AT_FDCWD, "terraform.d/plugins/linux_amd64/terraform-provider-shell", {st_mode=S_IFREG|0755, st_size=29781237, ...}, AT_SYMLINK_NOFOLLOW) = 0 but discarding the plugin it finds as unusable (which might be something to do with the plugin or its versionn or the way its built or it might not, I don't know.
Reproducing
Create a root module that depends on a custom provider plugin as stored in terraform.d using the 0.13 style provider directory path.
In the root module:
terraform init
cd terraform.d
mv plugins ../../../.
ln -snf ../../../plugins
cd ..
terraform init
The text was updated successfully, but these errors were encountered:
danieldreier
added
new
new issue not yet triaged
explained
a Terraform Core team member has described the root cause of this issue in code
and removed
new
new issue not yet triaged
labels
Aug 5, 2020
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
ghost
locked as resolved and limited conversation to collaborators
Oct 10, 2020
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
bugcoreexplaineda Terraform Core team member has described the root cause of this issue in codev0.13Issues (primarily bugs) reported against v0.13 releases
Terraform Version
Terraform Configuration Files
Description
If you are providing a custom provider plugin binary via the terraform.d directory in a root module, you get different behaviour depending on whether the plugins directory inside terraform.d is a symlink.
If it is not a symlink, the new style directory emulating a registry works as normal.
If it is a symlink, then the new style directory seems to be ignored.
In either case you get
write(2, "2020/07/28 18:02:18 [DEBUG] will search for provider plugins in terraform.d/plugins\n", 84) = 84
In either case the old style path of
terraform.d/plugins/linux_amd64/terraform-provider-shell
is enumerated, going so far as:newfstatat(AT_FDCWD, "terraform.d/plugins/linux_amd64/terraform-provider-shell", {st_mode=S_IFREG|0755, st_size=29781237, ...}, AT_SYMLINK_NOFOLLOW) = 0
but discarding the plugin it finds as unusable (which might be something to do with the plugin or its versionn or the way its built or it might not, I don't know.Reproducing
terraform init
cd terraform.d
mv plugins ../../../.
ln -snf ../../../plugins
cd ..
terraform init
The text was updated successfully, but these errors were encountered: