Skip to content

Conversation

@marcabreracast
Copy link
Collaborator

@marcabreracast marcabreracast commented Nov 21, 2025

Description

This PR introduces a new field custom_openssl_cipher_config_tls13 into the advanced_cluster resource.

Note that this field will now coexist with custom_openssl_cipher_config_tls12, as both fields are configurable.

Link to any related issue(s): CLOUDP-350448

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

Documentation has been added to address the new field, however PR #3903 will be merged in a synced way along with this one.

@marcabreracast
Copy link
Collaborator Author

Note that advanced_cluster tests are failing in cloud-dev for the past days (see Test Suite failures), however I ran the tests against QA environment and they are successful and passing all checks.

@marcabreracast marcabreracast marked this pull request as ready for review November 21, 2025 15:18
@marcabreracast marcabreracast requested review from a team as code owners November 21, 2025 15:18
Copilot AI review requested due to automatic review settings November 21, 2025 15:18
@github-actions
Copy link
Contributor

APIx bot: a message has been sent to Docs Slack channel

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adds support for TLS 1.3 custom cipher configuration in the advanced_cluster resource by introducing the custom_openssl_cipher_config_tls13 field. This field works alongside the existing custom_openssl_cipher_config_tls12 field, allowing users to configure custom cipher suites for both TLS versions independently.

Key changes:

  • Added custom_openssl_cipher_config_tls13 field to schema, model, and conversion logic
  • Updated test helpers and added new test case for TLS 1.3 cipher configuration
  • Updated documentation for all related resources and data sources

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

Show a summary per file
File Description
internal/service/advancedcluster/schema.go Adds TLS 1.3 cipher config field to schema and model definitions
internal/service/advancedcluster/resource_test.go Updates test helpers and adds new test case for TLS 1.3 ciphers
internal/service/advancedcluster/plan_modifier.go Updates attribute change mapping to include TLS 1.3 field
internal/service/advancedcluster/model_to_ClusterDescription20240805.go Adds TLS 1.3 field to cluster configuration conversion
internal/service/advancedcluster/model_ClusterDescriptionProcessArgs20240805.go Updates conversion logic and renames function for reusability
docs/resources/advanced_cluster.md Documents the new TLS 1.3 cipher configuration field
docs/data-sources/advanced_clusters.md Documents the new field in plural data source
docs/data-sources/advanced_cluster.md Documents the new field in singular data source
.changelog/3912.txt Adds changelog entries for the enhancement

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +64 to +68
var customCipherConfigTLS13 *[]string
if !inputAdvConfig.CustomOpensslCipherConfigTls13.IsNull() && !inputAdvConfig.CustomOpensslCipherConfigTls13.IsUnknown() {
customCipherConfigTLS13 = conversion.Pointer(conversion.TypesSetToString(ctx, inputAdvConfig.CustomOpensslCipherConfigTls13))
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not done for tls1.2, why is it needed for 1.3?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For TLS 1.2 I left the existing behaviour unchanged in this PR because the current tests and recorded fixtures rely on encountering an empty array shape, but introducing customOpensslCipherConfigTls13 the same way (always sending an empty array when unset) was causing unit test failures.

I think it would be better to omit customOpensslCipherConfigTls12 when it isn’t configured, unless I'm missing some additional context. Right now, we send it as an empty array when the set is empty, and the API ignores that value, so omitting the field entirely would be my preference.

I’ve added a "omit when unset” behaviour only for customOpensslCipherConfigTls13 so we don’t introduce a new always‑empty field into the payload, and both existing and new tests pass. I think we could align TLS 1.2 to the same pattern if we agree it's a good implementation in terms of consistency.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, thanks! Yes, I would aim to align both as well.

Copy link
Member

@lantoli lantoli Nov 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

those "mockable" unit tests are not an issue, it's ok that they fail if request or response payloads change, in that case testdata files must be re-captured with new payloads, I don't think this should influence the decision.

It's the same creating the cluster, but I think it's different in cluster updates: I think sending empty will clear the attribute whereas not sending it will probably keep the current value.

I recommend to create an acc test with an update from 1.2 to 1.3, I suppose it will be a very typical use case in customers with existing clusters, something like:

  • Step 1: Define a cluster with TLS1_2 and customOpensslCipherConfigTls12
  • Step 2: Update the cluster cluster to TLS1_3 and customOpensslCipherConfigTls13 (to check customOpensslCipherConfigTls12 is cleared)
  • Step 3: Same step 1 - TLS1_2 and customOpensslCipherConfigTls12 (to check customOpensslCipherConfigTls13 is cleared)

and see if cluster upgrades successfully from TLS1_2 to TLS1_3 and back

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok sounds good then, I will follow-up on this and will create an additional acceptance test

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

edited the acc test to have 3 steps and more certainty that it works as expected.

to clarify about the mockable unit tests, they shouldn't influence how to handle the attributes (we can re-generate the test data), and if customOpensslCipherConfigTls12 and customOpensslCipherConfigTls13 are implemented equally in Atlas, I think we should also follow the same approach for them in Terraform, which ever we think it's better instead of mixing approaches.


* `default_write_concern` - [Default level of acknowledgment requested from MongoDB for write operations](https://docs.mongodb.com/manual/reference/write-concern/) set for this cluster. MongoDB 6.0 clusters default to [majority](https://docs.mongodb.com/manual/reference/write-concern/).
* `javascript_enabled` - When true, the cluster allows execution of operations that perform server-side executions of JavaScript. When false, the cluster disables execution of those operations.
* `minimum_enabled_tls_protocol` - Sets the minimum Transport Layer Security (TLS) version the cluster accepts for incoming connections. Valid values are:
Copy link
Collaborator

@manupedrozo manupedrozo Nov 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will 1.3 be added to this attribute in another task? Not sure if we validate on the provider side, might already be possible to set 1.3 and just need to update the docs.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's already added. The field custom_openssl_cipher_config_tls13 is present in the docs, and it's implemented in the plural data source, but the TLS1_3 addition part of this file is done by the docs team in this PR: #3903.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect!

Copy link

@jromo-mdb jromo-mdb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants