[BUG] ovh_cloud_project_database_mongodb_user password attribute is not tagged as changing when password_reset string changes

[mig4ng]

Describe the bug

Bug when updating a ovh_cloud_project_database_mongodb_user by triggering a change at the password_reset. The plan is not aware that the password will change. This causes problems when other resources use this password.

E.g.:
I have a Kubernetes Secret that is created using the password from the ovh_cloud_project_database_mongodb_user.
When I trigger a change in the password_reset of the ovh_cloud_project_database_mongodb_user resource, it shows it will update the ovh_cloud_project_database_mongodb_user:

Terraform will perform the following actions:

  # ovh_cloud_project_database_mongodb_user.cluster_secret_user will be updated in-place
  ~ resource "ovh_cloud_project_database_mongodb_user" "cluster_secret_user" {
        id             = "<redacted>"
        name           = "userexample@admin"
      ~ password_reset = "15 February 2024 17:04 GMT" -> "15 February 2024 17:05 GMT"
        # (6 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

I am using 15 February 2024 17:04 GMT as the password_reset abritrary string. In this plan, the expected was for the password atribute to be marked to change ~ password = (sensitive value) or similar, instead of being labeled as unchanged attributes.

This causes, that the Kubernetes secret is not updated in this apply. However, when I run apply again, this happens:

Terraform will perform the following actions:

  # kubernetes_secret_v1.mongo_cluster_secret will be updated in-place
  ~ resource "kubernetes_secret_v1" "mongo_cluster_secret" {
      ~ data                           = (sensitive value)
        id                             = "example/mongo-cluster-secret"
        # (3 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

To mitigate this, I tried adding a lifecycle replace_triggered_by atrribute to the Kubernetes Secret.

lifecycle {
    replace_triggered_by = [
      ovh_cloud_project_database_mongodb_user.cluster_secret_user.password_reset
    ]
  }

However, this resulted in the following error:

╷
│ Error: Provider produced inconsistent final plan
│
│ When expanding the plan for kubernetes_secret_v1.mongo_cluster_secret to
│ include new values learned so far during apply, provider
│ "registry.terraform.io/hashicorp/kubernetes" produced an invalid new value
│ for .data: inconsistent values for sensitive attribute.
│
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
╵

Since, Terraform knows there is a new value there, however, the value provided at the planing phase is different.

Terraform Version

Terraform v1.5.4
on darwin_arm64
+ provider registry.terraform.io/hashicorp/kubernetes v2.26.0
+ provider registry.terraform.io/ovh/ovh v0.37.0

OVH Terraform Provider Version

+ provider registry.terraform.io/ovh/ovh v0.37.0

Affected Resource(s)

Please list the resources as a list, for example:

• ovh_cloud_project_database_mongodb_user
• most likely other database user resources.

Terraform Configuration Files

# Only two resources are needed for the main configuration:
resource "ovh_cloud_project_database_mongodb_user" "cluster_secret_user" {
  service_name = var.ovh_project_id
  cluster_id   = var.ovh_mongodb_id
  name         = "userexample"
  password_reset = "15 February 2024 17:04 GMT"
  roles        = ["backup@admin", "dbAdminAnyDatabase@admin", "readAnyDatabase@admin", "readWriteAnyDatabase@admin", "restore@admin", "userAdminAnyDatabase@admin"]
}

resource "kubernetes_secret_v1" "mongo_cluster_secret" {
  depends_on = [ ovh_cloud_project_database_mongodb_user.cluster_secret_user ]

  lifecycle {
    replace_triggered_by = [
      ovh_cloud_project_database_mongodb_user.cluster_secret_user.password_reset
    ]
  }
  
  type = "kubernetes.io/opaque"

  metadata {
    name = "mongo-cluster-secret"
    namespace = "example"
  }

  data = {
    MONGO_USERNAME      = ovh_cloud_project_database_redis_user.cluster_secret_user.name
    MONGO_PASSWORD      = ovh_cloud_project_database_mongodb_user.cluster_secret_user.password
  }
}

Debug Output

Pasted above, in the bug description

Panic Output

Pasted above, in the bug description

Expected Behavior

Terraform should know about the password attribute change and make a plan to also edit resources that depend on it, in this case, update the Kubernetes Secret with the password too.

Actual Behavior

Described in detail above, however, it assumes password is an unchanged attribute, and either does nothing, or with the lifecycle it errors, with the error above.

Steps to Reproduce

1. Create a ovh_cloud_project_database_mongodb_user and another resource that depends on it's password (e.g. kubernetes_secret_v1). The mongo_db_user should have a password_reset attribute.
2. Apply this resources.
3. Change the password_reset string in order to trigger a password change.
4. At this point you have to alternatives. Either use the lifecycle in order to trigger the error. Or, just terraform apply.
5. If you did terraform apply the current state has a password for the mongo user, that is different from the one that is present in the Kubernetes Secret. So if you do terraform apply again, it will show you that the Kubernetes Secret needs to be updated to this new value.

References

Did not find any

Additional context

It would be nice to know, if the password changed from the UI. If you have direct contact with the OVH team that handle the UI, it would be nice to have the password_reset attribute to change whenever the Reset password button on the UI is clicked (e.g. to the current timestamp). This way, I would get configuration drift detection from Terraform.
Either this, or being able to disable password reset (or disable all changes all together) from the UI for certain users.

[yomovh]

Thanks for your issue, I have redirected it to the database product team.