-
Notifications
You must be signed in to change notification settings - Fork 548
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade to use TF SDK v2 #1175
Upgrade to use TF SDK v2 #1175
Conversation
"github.com/hashicorp/terraform-provider-vault/helper" | ||
|
||
"github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think usually local imports are after the others?
"github.com/hashicorp/terraform-provider-vault/helper" | |
"github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema" | |
"github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema" | |
"github.com/hashicorp/terraform-provider-vault/helper" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this is canonical but goimports
puts local imports first. Maybe just run goimports -w .
at the root of the repo? And that should make everything consistent, it certainly looks like this PR inherited a lot of pre-existing inconsistency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure what Goland uses, but it seems to group the local module's imports last.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like it defaults to gofmt
which groups the local packages last.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few more small comments. Have you also run the tests that require credentials and access to external systems? i.e. the database backends, anything that requires AWS creds, etc. Those tend to be skipped if the appropriate environment variables aren't set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM pending some minor comments from Theron! 👍
- go mod tidy - standardize imports
- make getJwtAuthBackendIfPresent() reusable by other callers
- use hashicorp/vault Docker repo.
- ci: move acceptance test environment to the test run
- drop extra environment debug
a5572a0
to
b3891ae
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😎
Just a thought that we'll probably want to manually run the enterprise-specific tests before releasing, since those aren't tested in CI right now.
👍 I tested locally against vault-enterprise and all tests passed. |
@benashz Can you expand on this a bit? Is there a way to prevent accidental write of the raw token value to the state file? |
@@ -122,9 +122,9 @@ func gcpAuthBackendRoleRead(d *schema.ResourceData, meta interface{}) error { | |||
log.Printf("[DEBUG] Read gcp auth backend role %q ID", path) | |||
|
|||
if resp == nil { | |||
d.SetId("") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that there are other places where we explicitly call d.SetId("")
before returning if the value (e.g. resp
) that we're about to reference is nil. How come we don't have to in this case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!
I did a bit of digging and this should actually be an error, since the role does exist. Looks like a discovered issue.
PR on its way!
Not that I am aware of. The TF team recommends persisting the state to encrypted storage. Adding a cautionary note for this resource might be a good mitigation? Some options that come to mind are:
|
The Vault Terraform provider is currently using v1 of the terraform-plugin-sdk, which is no longer seeing active feature development. The TF Plugin SDK v2 was released on July 30, 2020 and is considered to be the default SDK for all TF plugins. This PR includes the bulk of what is need to upgrade to v2. There are a few potentially breaking changes:
pgp_key
encryption on thevault_token
resource has been dropped. This is inline with upstream SDK changes.Community Note
Release note for CHANGELOG:
Output from acceptance testing: