- Notifications
You must be signed in to change notification settings - Fork 203
doc: Adds mongodbatlas_api_key_project_assignment
documentation, examples and migration guide #3465
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
base: CLOUDP-215112
Are you sure you want to change the base?
Conversation
APIx bot: a message has been sent to Docs Slack channel |
### Best Practices Before Importing | ||
- **Backup your Terraform state file** before making any changes. | ||
- **Review your current usage** of `mongodbatlas_project_api_key` and plan the migration for all affected resources. | ||
- **Test the migration in a non-production environment** if possible. |
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.
[nit] I would remove this
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 this can be a common section that can be referred in every migration doc, instead of "Review your current usage** of mongodbatlas_project_api_key
" we can rephrase this to be more generic like "Review your current usage** of deprecate resource or something"
``` | ||
2. **Import the existing API key into the API key resource:** | ||
```shell | ||
terraform import mongodbatlas_api_key.example <ORG_ID>-<API_KEY_ID> |
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.
Can we also support /
instead of -
to be more consistent?
```shell | ||
terraform import mongodbatlas_api_key_project_assignment.example <PROJECT_ID>/<API_KEY_ID> | ||
``` | ||
4. **Remove the old resource from the Terraform state:** |
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.
Is this a use-case for import
and removed
block?
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 was thinking the same
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.
yes, I have clarified that removed block can be used
A: Existing keys will continue to work, but we recommend following the migration guide to move to the new pattern. | ||
| ||
**Q: What if I have many project assignments?** | ||
A: You can use `for_each` or `count` with `mongodbatlas_api_key_project_assignment` to manage multiple assignments efficiently. |
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.
Do we have any examples of this?
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 point
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 there's no need, for_each count are terraform features. I added links to the official documentation for this features
| ||
Lastly, in MongoDB Atlas, all PAKs are Organization API keys. Once created, a PAK is linked at the organization level with an 'Organization Member' role. However, these Organization API keys can also be assigned to one or more projects within the organization. When a PAK is assigned to a specific project, it essentially takes on the 'Project Owner' role for that particular project. This enables the key to perform operations at the project level, in addition to the organization level. The flexibility of PAKs provides a powerful mechanism for fine-grained access and control, once their functioning is clearly understood. | ||
```hcl | ||
resource "mongodbatlas_api_key" "test" { |
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 if we want duplicate main.tf content here
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 it doesn't hurt to have it here IMO
} | ||
``` | ||
| ||
## Migration using import |
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.
Remember the "Does this work for modules"? And I think this doesn't, right?
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.
in any case we need an example specific for modules
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.
Because the old resource corresponds to 2 resources, moved block is not possible and this wouldn't work for modules because import is needed. Will add a "Does this work for modules" section
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.
@@ -1,16 +0,0 @@ | |||
| |||
# Create Programmatic API Key + Assign Programmatic API Key to 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.
question: shouldn't we still have these examples but just migrated to the new approach?
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 having the old pattern examples will be confusing and can lead to customers referencing those even if we now recommend the new pattern. Removing them and only having a single (new example) is better
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.
got it, but aren't we removing the examples on how to use mongodbatlas_access_list_api_key
?
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 point, I have added that back to the api_key example in 669bb50
| ||
While this is not our recommended approach, you can still continue to use the `mongodbatlas_project_api_key` resource. If you are creating a new configuration, use the `mongodbatlas_api_key_project_assignment` resource. | ||
| ||
## Does this work for modules? |
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.
Thanks for the section, but I would remove it from here and put this text into "## Migration using Modules"
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.
Makes sense, done in dc0790b
Co-authored-by: Leo Antoli <430982+lantoli@users.noreply.github.com>
| ||
## Main Changes Between Patterns | ||
| ||
| Old Pattern (`mongodbatlas_project_api_key`) | New Pattern (`mongodbatlas_api_key` + `mongodbatlas_api_key_project_assignment`) | |
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.
nit: This table is hard to read when using https://registry.terraform.io/tools/doc-preview, might be worthing just putting as sub titles
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.
changed in e0ba552
5. **Remove the old resource block from your configuration** | ||
6. **Run `terraform plan` to review the changes.** | ||
- Ensure that Terraform does not plan to delete or recreate your API keys or assignments. | ||
- **Note:** After import, Terraform may show an in-place update for attributes like `org_id` on the `mongodbatlas_api_key` resource. This is expected and only updates the Terraform state to match your configuration; it does not change the actual resource in Atlas. You can safely apply this change. |
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 curious is this something we can fix in api_key import?
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 we could but not sure if it would be considered as a breaking change or not. To fix it we would need to change the behavior of the Read. If you see the import of the api_key resource, the encoded Id
attribute is set, and then on the Read, more attributes are set but not org_id
, so when the terraform apply after the import is done, a change is detected. e.g.
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: ~ update in-place Terraform will perform the following actions: # module.api_key_assignment.mongodbatlas_api_key.this will be updated in-place ~ resource "mongodbatlas_api_key" "this" { ~ description = "Legacy module-managed API Key" -> "Module-managed API Key" id = "YXBpX2tleV9pZA==:Njg2N2E1ODg2YTdlOGQ0M2Q2ZTdlODFl-b3JnX2lk:NjBkZGY1NWMyN2E1YTIwOTU1YTcwN2Q3" + org_id = "60ddf55c27a5a20955a707d7" # (3 unchanged attributes hidden) } Plan: 0 to add, 1 to change, 0 to destroy.
open to discuss if this change is worth doing now
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.
if org_id will be set every time in Read() then this would be a breaking change as it would result in non-empty plans right?
terraform import 'module.<module_name>.mongodbatlas_api_key.<name>' <ORG_ID>-<API_KEY_ID> | ||
terraform import 'module.<module_name>.mongodbatlas_api_key_project_assignment.<name>' <PROJECT_ID>/<API_KEY_ID> |
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.
Some customers who have platform and app teams have very distinct responsibilities. App teams, who would be the ones having to run this comment, don't have access to import
capabilities. I think this should be converted into adding the import
block in the configuration rather than as a command. I believe that should work
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 also very worried that this is the only suggestion we can make. Imagine a very big customer with hundreds of app teams, each team is expected to do that if they want to migrate to our recommended approach. That's never going to happen.
is the project_assignment
an idempotent type of resource? What I mean is: if mongodbatlas_api_key_project_assignment
is being created in TF but that assignment already exists, will it fail? or simply succeed? if that's the case we could recommend a moved
from project_api_key
to api_key
and then the mongodbatlas_api_key_project_assignment
would be defined as "new" resources
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.
added explicit mention of import block throughout the doc in ec95e5f.
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 % nits
@@ -0,0 +1,229 @@ | |||
--- | |||
page_title: "Migration Guide: Project API Key to API Key + Assignment" |
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.
page_title: "Migration Guide: Project API Key to API Key + Assignment" | |
page_title: "Migration Guide: Project API Key to API Key + Project Assignment" |
### Best Practices Before Importing | ||
- **Backup your Terraform state file** before making any changes. | ||
- **Review your current usage** of `mongodbatlas_project_api_key` and plan the migration for all affected resources. | ||
- **Test the migration in a non-production environment** if possible. |
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 this can be a common section that can be referred in every migration doc, instead of "Review your current usage** of mongodbatlas_project_api_key
" we can rephrase this to be more generic like "Review your current usage** of deprecate resource or something"
5. **Remove the old resource block from your configuration** | ||
6. **Run `terraform plan` to review the changes.** | ||
- Ensure that Terraform does not plan to delete or recreate your API keys or assignments. | ||
- **Note:** After import, Terraform may show an in-place update for attributes like `org_id` on the `mongodbatlas_api_key` resource. This is expected and only updates the Terraform state to match your configuration; it does not change the actual resource in Atlas. You can safely apply this change. |
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.
if org_id will be set every time in Read() then this would be a breaking change as it would result in non-empty plans right?
Description
Adds
mongodbatlas_api_key_project_assignment
documentation, examples and migration guide.Also removed the examples that were using the old patterns for API key assignment to projects to avoid customers from referencing those.
This corresponds to the documentation necessary for #3461
Link to any related issue(s): CLOUDP-215112
Type of change:
Required Checklist:
Further comments