[New Resource] api_key_project_assignment

[aristosvo]

Description

Please include a summary of the fix/feature/change, including any relevant motivation and context.

Link to any related issue(s):
Resolves #2030

Type of change:

• Bug fix (non-breaking change which fixes an issue). Please, add the "bug" label to the PR.
• New feature (non-breaking change which adds functionality). Please, add the "enhancement" label to the PR. A migration guide must be created or updated if the new feature will go in a major version.
• Breaking change (fix or feature that would cause existing functionality to not work as expected). Please, add the "breaking change" label to the PR. A migration guide must be created or updated.
• This change requires a documentation update
• Documentation fix/enhancement

Required Checklist:

• I have signed the MongoDB CLA
• I have read the contributing guides
• I have checked that this change does not generate any credentials and that they are NOT accidentally logged anywhere.
• I have added tests that prove my fix is effective or that my feature works per HashiCorp requirements
• I have added any necessary documentation (if appropriate)
• I have run make fmt and formatted my code
• If changes include deprecations or removals I have added appropriate changelog entries.
• If changes include removal or addition of 3rd party GitHub actions, I updated our internal document. Reach out to the APIx Integration slack channel to get access to the internal document.

Further comments

[marcosuma]

@aristosvo, thank you for your PR. While we can't merge this PR right away, we are considering what is the best solution to fix this issue. I've initiated a discussion with the team and we will try to make a decision.

[aristosvo]

@marcosuma Thanks for letting me know. I'm not on a tight schedule here, but it would help for our future upgrade (still stuck at 1.11) and also restructuring our Terraform/organization of MongoDB.

Thanks in advance!

[github-actions]

This PR has gone 7 days without any activity and meets the project’s definition of "stale". This will be auto-closed if there is no new activity over the next 7 days. If the issue is still relevant and active, you can simply comment with a "bump" to keep it open, or add the label "not_stale". Thanks for keeping our repository healthy!

[aristosvo]

bump

[github-actions]

This PR has gone 7 days without any activity and meets the project’s definition of "stale". This will be auto-closed if there is no new activity over the next 7 days. If the issue is still relevant and active, you can simply comment with a "bump" to keep it open, or add the label "not_stale". Thanks for keeping our repository healthy!

[aristosvo]

bump

[github-actions]

This PR has gone 7 days without any activity and meets the project’s definition of "stale". This will be auto-closed if there is no new activity over the next 7 days. If the issue is still relevant and active, you can simply comment with a "bump" to keep it open, or add the label "not_stale". Thanks for keeping our repository healthy!

[aristosvo]

bump

[github-actions]

This PR has gone 7 days without any activity and meets the project’s definition of "stale". This will be auto-closed if there is no new activity over the next 7 days. If the issue is still relevant and active, you can simply comment with a "bump" to keep it open, or add the label "not_stale". Thanks for keeping our repository healthy!

[marcosuma]

Keeping this open. We still haven't managed to prioritise this conversation.

[aristosvo]

That is quite a bummer, as we would like to upgrade from 1.11 before the EOL of 6.0 (there are some nasty issues if you want to upgrade). Upgrading within our current structure is not really possible without this feature with Terraform, so we probably will have to test and role our own fork of the provider for this.

Can we speed this up in any way, for instance by escalating via our support contract?

[marcosuma]

Hi @aristosvo, I am sorry to hear that. I'll do my best to provide you with an update in the following days.

[marcosuma]

Hi @aristosvo , once again thank you and your team for your patience. I wanted to update you here by saying that we've decided to fix this problem by adding the project_assignment functionality to the mongodbatlas_api_key resource. By adding project_assignment to this resource, you should be able to use this resource to achieve your needs. You will not need to use mongodbatlas_project_api_key and we will clarify that in our documentation.

While this PR option was also on the table, we prefer at this time not to add a new resource, as that would make the overall customer journey a bit more challenging to explain overall.

Does that help? Do you have any concerns to share?

I can't give you an exact timeline but since we've now made a decision we'll try to prioritise this work.

[aristosvo]

Hi @marcosuma !

Thanks for your response. As I understand your concern on customer journey, as a customer I prefer small resources, as this makes rework easier.

With regard to your proposed solution: This will not work unfortunately, as we create the project (with API key assignment, 1.11) in one run, together with the cluster creation (which needs the project assignment).

The dependency tree with a separate resource makes this possible in a simple way, opening up the possibility for us to refactor quick and easy.

With one resource I don't think this is practically possible, as we'd have to link dependencies on the API key resource to child modules while passing the project id back from the child module to the root module.

We want to improve our operating model, but without the flexibility of an API key project assignment resource we can't even start with a simple upgrade to the latest version.

Can you share a link on the 'ideal' customer journey?

[marcosuma]

@aristosvo thanks for sharing more about your use case. If I understand it correctly:

• you have a "root" module that handles the API key (of an organization)
• then you have multiple "child" modules, each child module contains project and cluster (and other things)

You want to be able to assign the key to a project in the child module, which means the root module "passes" the API key ID and then the child module does the rest.

Is my understanding correct?

[aristosvo]

Approximately, only diff is that we don't create the API key via TF:

• We have manually/via CLI an API key defined
• We put this key in AWS Secrets Manager, use it to authenticate Terraform towards Atlas
• We have a root module per environment which defines ~15 projects, containing ~15 clusters
• The project config and cluster config options are defined in a module, called from the root module
• Before we can create a cluster, the API key needs permission on the project, in the same run the project is possibly created

[github-actions]

This PR has gone 7 days without any activity and meets the project’s definition of "stale". This will be auto-closed if there is no new activity over the next 7 days. If the issue is still relevant and active, you can simply comment with a "bump" to keep it open, or add the label "not_stale". Thanks for keeping our repository healthy!