-
Notifications
You must be signed in to change notification settings - Fork 50
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
HCE-339 feat multi project #454
Conversation
2b0e1f1
to
4958175
Compare
5d6c610
to
9ddf7f0
Compare
aca3510
to
9ddf7f0
Compare
c33f375
to
f8c0d9e
Compare
* add validator for resource level project id, hce-339 * optionall read hvn project id from resource or provider config * adds project id validator unit tests * revise tests * WIP - investigate multiproject acceptance testing * multiproject unit tests (GTG), and acceptance tests (WIP) * create helper to retrieve project ID * use project ID helper when creating hvn * fix linting/incorporate comments * implement multiproject planonly acceptance test coverage * swap validator for isUUID * update datasource to support optional project id * reduce variables * add provider method to create project * update documentation * fix project err to ensure it returns complete err * add project validator to provider, update test error match --------- Co-authored-by: Brenna Hewer-Darroch <21015366+bcmdarroch@users.noreply.github.com>
* add project id * typo
* add project_id to consul resources * typo * typo
* add project id to aws network peering resource * add project ID field to datasource * update docs
* add project_id * typo * missing resource
* add project_id * typo
* add multi proj guide template * add TF examples * regen doc * update warning * clarify default project when no project set
* allow explicit project id on import * add project id to other resources * linting and test coverage * more explicit comments
2d1516a
to
3a0e48f
Compare
|
||
### Override provider project with resource project | ||
|
||
Projects may be set at both the resource and provider level. The resource-configured project is always preferred over the provider-configured project. |
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 discussed with @glasner about setting the project_id
at the resource v.s. the provider config level in the use case of using multiple projects for multiple resources.
The general guidance from Jordan is to:
-
Use Provider Alias (docs here) to create aliases of providers with individual configurations (can have one alias per project). It would remove the need to assign projects to each resource, especially when there are multiple resources referencing different products (like HCP Packer and HCP Vault Secrets) to be created.
-
If there is only one HCP product resource with a limited resource count, like a few data sources referencing different HCP Vault Secret applications in different HCP projects, setting the project at the resource level is optimal.
Let me know if I missed anything in our conversation, @glasner .
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.
To clarify: this is not a blocker, but a suggested change, to follow the Provider’s config best practice.
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.
🎉 😅
2a72000
to
118996b
Compare
@@ -65,6 +66,14 @@ func resourceVaultCluster() *schema.Resource { | |||
ValidateDiagFunc: validateSlugID, | |||
}, | |||
// Optional fields | |||
"project_id": { | |||
Description: "The ID of the HCP project where the Vault cluster is located.", |
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.
maybe it'd useful to say that if this parameter is not specified then the oldest project will be targeted
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.
Thank you for your feedback, I've created a ticket to address it in a separate PR. Since it is a large change, I will discuss it with the team and we will implement it separately.
🛠️ Description
This PR includes changes to support adding project ID at the provider level. When no project ID is specified, the provider selects as default the ID of the first attached project.
Jira 🎟️ - Add project ID to provider config
🏗️ Acceptance tests
Output from acceptance testing: