fix: implement proper ImportState for organization membership resource - #7
fix: implement proper ImportState for organization membership resource#7benc-vorwerk wants to merge 2 commits into
Conversation
The previous ImportState implementation used PassthroughID which doesn't work for this resource since it requires organization credentials to authenticate API calls. Changes: - Replace PassthroughID with custom import logic that parses the import ID format: membership_id,organization_public_key,organization_private_key - Validate credentials by fetching the membership from the API - Set all state attributes using resp.State.Set() for proper state initialization - Remove unused path import Add comprehensive import tests: - Successful import with all fields verified - Invalid format with missing parts - Invalid format with too many parts - Invalid format with only two parts - API error handling Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
|
Steffen911
left a comment
Steffen911
left a comment
There was a problem hiding this comment.
Thank you a lot! The overall change seems reasonable. @pkalemba Could you also take a look since the initial PR came from your end?
| orgPublicKey := importParts[1] | ||
| orgPrivateKey := importParts[2] |
There was a problem hiding this comment.
@benc-vorwerk Do you know whether this implies that the organization private key gets added into the state in clear text? Ideally, we should consider or keep it a secret.
There was a problem hiding this comment.
@Steffen911 yes, with the current schema/import implementation the org private key will be persisted in Terraform state (Sensitive only redacts display).
separately, passing it via the CLI import ID is also not ideal due to shell history/logging. I can update docs to recommend import blocks with variables, and we can discuss a bigger refactor (e.g., provider-level org credentials / aliases) if we want to keep secrets out of state entirely.
There was a problem hiding this comment.
hello @Steffen911, do you want me to add documentation for all resources here or refactor it to support organization as provider? similar to what databricks terraform does with separate provider for account and workspaces.
…ider - Introduced multi-organization management example with provider aliases. - Implemented organization-level credentials to reduce redundancy in resource definitions. - Updated resources to resolve organization credentials using a fallback mechanism. - Enhanced import functionality to support both new and legacy formats for organization credentials. - Added comprehensive documentation for usage, best practices, and examples. - Modified existing resources to utilize organization-level credentials where applicable.
|
@Steffen911 I refactored this to maintain backward compatibility by using the organization as the provider when creating projects and assigning memberships. |
3 participants
The previous ImportState implementation used PassthroughID which doesn't work for this resource since it requires organization credentials to authenticate API calls.
Changes:
Add comprehensive import tests: