terraform: only use embedded plugins when release tag is set

[abhinavdahiya]

/cc @wking

[wking]

ff3c430 looks good to me, but we'll need to work harder to train users who want this isolation to use released installers. CC @sallyom, @ironcladlou, @RobertKrawitz, in case they want to chime in before we land this.

[abhinavdahiya]

but we'll need to work harder to train users who want this isolation to use released installers

developers (trackingmaster) can be expected to be more informed compared to users using released versions.

[ironcladlou]

What's the use case for using non-vendored plugins?

[abhinavdahiya]

What's the use case for using non-vendored plugins?

so that we can test newer versions of plugins by putting them in ~/.terraform.d/plugins without changing the vendored ones for developer testing

[ironcladlou]

What's the use case for using non-vendored plugins?

so that we can test newer versions of plugins by putting them in ~/.terraform.d/plugins without changing the vendored ones for developer testing

Is it fair to say this comes at the expense of re-introducing external dependencies and steps for development builds?

I don't know what's more common, using the vendored plugins for development or using custom plugins, so I can't say who it makes more sense to optimize for. Speaking only for myself, I never use custom plugins, and if I did I would be willing to jump through hoops to do so.

[abhinavdahiya]

Is it fair to say this comes at the expense of re-introducing external dependencies and steps for development builds?

The development builds will continue to use vendored plugins.. but it allows you to override the vendored by placing the corresponding plugin in ~/.terraform.d/plugins. This is about setting priority for finding plugins for terraform
release -> only vendored
non release - > ~/.terraform.d/plugins > vendored

[RobertKrawitz]

/lgtm

Problems with version skew in the terraform plugins have very non-obvious symptoms. This is one way we can make life less gratuitously difficult.

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: abhinavdahiya, RobertKrawitz

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [abhinavdahiya]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[abhinavdahiya]

/retest

[ironcladlou]

Thanks for the clarification — it wasn't obvious to me that this just adds another entry to a precedence list!