ovh/terraform-provider-ovh

[BUG] TF apply goes timeout if trying to apply IP restriction(s) (existing or not) on a MongoDB database

fbarutel opened this issue · 6 comments

fbarutel commented

Describe the bug

When trying to apply IP restriction(s) (existing or not) on a MongoDB database, the terraform apply goes on this message until timeout (default timeout value is 20 minutes duration) :
ovh_cloud_project_database_ip_restriction.iprestriction: Still creating...

Nevertheless, as I can see them within the OVH manager HMI, the IP restrictions have been indeed applied successfully despite the wrong "PENDING" status retrieved via the ovh terraform provider.

Terraform Version

Terraform v1.6.6
on windows_amd64

OVH Terraform Provider Version

0.36.1

Affected Resource(s)

  • ovh_cloud_project_database_ip_restriction

Terraform Configuration Files

terraform {
  required_providers {
    ovh = {
      source  = "ovh/ovh"
      version = "~>0.36.1"
    }
  }
}

variable "mongodb_ovh_parameters" {
  type = object({
    plan      = string
    flavor    = string
    disk_size = number
    version   = string
  })
  default = {
    plan      = "discovery",
    flavor    = "db2-free",
    disk_size = null,
    version   = "6.0"
  }
}

provider "ovh" {
  # Configuration options
  endpoint = "ovh-eu"

  # Test rapide avec le Token créé pour l'occasion
  application_key    = "xxxxxxxxxxxxxxxxx"
  application_secret = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx""
  consumer_key       = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}

variable "mongodb_ovh_parameters" {
  type = object({
    plan      = string
    flavor    = string
    disk_size = number
    version   = string
  })
  default = {
    plan      = "discovery",
    flavor    = "db2-free",
    disk_size = null,
    version   = "6.0"
  }
}

resource "ovh_cloud_project_database" "mongodb_mdr" {
  service_name = data.terraform_remote_state.mdr_fundations_part1.outputs.cloud_project_id
  description  = "Test MongoDB for application purposes"
  engine       = "mongodb"
  plan         = var.mongodb_ovh_parameters.plan
  flavor       = var.mongodb_ovh_parameters.flavor
  # If disk_size parameter has been set in variable mongodb_ovh_parameters.disk_size the use it, otherwise try to retrieve minimum value for the selected flavor
  # Value to be retrieved in Gb, except for the flavor "db2-free" for which the value is '512' so in Mb
  disk_size = var.mongodb_ovh_parameters.disk_size != null ? var.mongodb_ovh_parameters.disk_size : local.flavors_capabilities[var.mongodb_ovh_parameters.flavor]
  version   = var.mongodb_ovh_parameters.version
  nodes {
    region = "GRA"
  }
  nodes {
    region = "GRA"
  }
  nodes {
    region = "GRA"
  }
}

# BUG de Timeout du Provider OVH : la modification s'applique mais retourne un fail à Terraform qui considère qu'il ne l'a pas appliqué, et arrête le déploiement sur ce fail bien évidemment
# => Conséquence : impossible d'utiliser les restrications d'adresses IP ou plages IPs sur base MongoDB (ca marche très bien sur PostgreSQL)
resource "ovh_cloud_project_database_ip_restriction" "mongodb_mdr_iprestriction_office" {
  depends_on = [ovh_cloud_project_database.mongodb_mdr]

  cluster_id   = ovh_cloud_project_database.mongodb_mdr.id
  engine       = ovh_cloud_project_database.mongodb_mdr.engine
  service_name = data.terraform_remote_state.mdr_fundations_part1.outputs.cloud_project_id
  description  = "Office"
  ip           = "xxx.xxx.xxx.xxx/29"
}

resource "ovh_cloud_project_database_ip_restriction" "mongodb_mdr_iprestriction_homeoffice" {
  depends_on = [ovh_cloud_project_database.mongodb_mdr]

  cluster_id   = ovh_cloud_project_database.mongodb_mdr.id
  engine       = ovh_cloud_project_database.mongodb_mdr.engine
  service_name = data.terraform_remote_state.mdr_fundations_part1.outputs.cloud_project_id
  description  = "Home Office"
  ip           = "yyy.yyy.yyy.yyy/32"
}

Debug Output

terraform_mongodb_iprestricton_debug_output_20240113.log

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

What should have happened?
The status of the successfully-applied IP restrictions should had been "READY" value during the terraform apply phase, instead of being stuck to "PENDING" value.

Actual Behavior

What actually happened?

Steps to Reproduce

  1. export TF_LOG=DEBUG
  2. export TF_LOG_PATH=./terraform_mongodb_iprestricton_debug_output_20240113.log
  3. terraform apply -auto-approve

References

GitHub issues (open or closed) or Pull Requests to be linked :

Pull Request GH-489 associated to issue GH-469 seems to have solved very similar issue with PostgreSQL as least, but may have not solved the MongoDB case (or a regression occured in the meantime)

Additional context

For information, I also reproduced the same behavior with terraform fork opentofu, gone GA this 10-Jan-2024 with 1.6.0 version.

lpatte commented

I can reproduce it.
Look like an issue on API side with Mongodb Discovery. I'm on it to fix it in the API.
I will test it, but I think nothing to do Terraform provider side.

  • 👍1
lpatte commented

Should be fixed now.
Thank you for this issue report which helped to fix some issues of the IP restriction API on MongoDB Discovery.
As I thought, nothing to do in the Terraform provider.

fbarutel commented

I've just tested successfully your fix with the same initial case, so I'm closing this issue.

apinter commented

@lpatte was adding new addresses to the mongo authorized ips, but I still see this issue happening. I posted some screenshots on the OVH Discord. I don't know if it has anything to do with the terraform side, but my guess is that it is not. I added the same addresses to psql and mysql using the same for_each method that worked fine, while the mongo side is keep trying to add the addresses. 4 out of 3 address were added fine, the last one failed. With larger deployments we have we're sadly not talking about 4 addresses only, which makes life frustrating as we're wasting 20minutes each time from our lives. The fun bit is that the address gets added as it is visible on the wUI, but never makes it back to the TF state file.

For reference I used the following config:

provider "ovh" {
  endpoint           = "ovh-eu"
  application_key    = var.ovh_app_key
  application_secret = var.ovh_app_secret
  consumer_key       = var.ovh_consumer_key
}
terraform {
  required_providers {
      ovh = {
      source = "ovh/ovh"
      }
    }
  

backend "http" {
  address        = "https://[REDACTED]"
  lock_address   = "https://[REDACTED]"
  unlock_address = "https://[REDACTED]"
  lock_method    = "POST"
  unlock_method  = "DELETE"
  retry_wait_min = 5
  }
}


variable "authorized_networks_dev_ovh" {
  description = "List of authorized networks to be used for managed databases"
  type = map(any)
  default = {
    cfae9b = {
      description  = "cfae9b"
      ip           = "135.125.245.220/32"
    }
    ad903c = {
      description  = "ad903c"
      ip           = "57.129.32.209/32"
    }
    b8bb2a = {
      description  = "b8bb2a"
      ip           = "57.129.32.160/32"
    }
    "79cfe5" = {
      description  = "79cfe5"
      ip           = "57.129.30.199/32"
    }
  }
}

resource "ovh_cloud_project_database_ip_restriction" "ovh-dev-cluster-mongo" {
    for_each     = var.authorized_networks_dev_ovh
    service_name = var.ovh_service_name
    cluster_id   = ovh_cloud_project_database.mongodb.id
    engine       = ovh_cloud_project_database.mongodb.engine
    description  = each.value.description
    ip           = each.value.ip
}

What is not happening any more is the delayed error response if the address is already present on the OVH side. This issue has been plaguing our experience for the past 2ish months now.

EDIT: removing authorized addresses seems to work fine.

lpatte commented

Can you confirm me that this issue is on a Mongodb with a plan Production (Not Discovery like original poster config) ?
I can reproduce it on a MongoDB Production.
Again an API issue i didn't catch with only 2 IP in the previous fix.

  • 👍1
lpatte commented

Should be fixed now.

  • 🚀1