MySQL RDS: New Instance Classes

[deem1978]

Hello everyone,
I was creating a new RDS Instance with a module that I use since years. The instance class is the ds.mysql.c2.medium. Running the pipeline I got an error:
module.rds.module.rds.opentelekomcloud_rds_instance_v3.main: Creating... ╷ │ Error: error creating new RDSv3 instance: Bad request with: [POST https://rds.eu-de.otc.t-systems.com/v3/d778e0ccb2964bf2bd8ec1e740a20d00/instances], error message: {"error_msg":"Invalid specification code.","error_code":"DBS.280434"} │ │ with module.rds.module.rds.opentelekomcloud_rds_instance_v3.main, │ on .terraform/modules/rds.rds/terraform/modules/terraform-otc-rds/main.tf line 107, in resource "opentelekomcloud_rds_instance_v3" "main": │ 107: resource "opentelekomcloud_rds_instance_v3" "main" {

So I wrote to OTC client service and they told me that instance classes are changed and I got the list of the new one. The instance I picked up is the db.n1.medium.2.mysql, but I still get the same error.
I use the terraform provider version 1.36.56.
As previous said, the module I use is working since years, I deployed about 30 instances with it.
Anyone has an idea?
I appreciate any help.
Best
Davide

[deem1978]

So yes, the instances names are completely changed https://www.open-telekom-cloud.com/_Resources/Persistent/d/3/0/5/d305d70f930a3bf97d4a409ff906f328a31b4d5f/open-telekom-cloud-leistungsbeschreibung-tdg.pdf and the volume types too (see https://www.open-telekom-cloud.com/de/support/release-notes/evs-common-i-o-erreicht-am-01-01-2026-end-of-life-letzter-aufruf): COMMON and ULTRAHIGH are not more supported for new instances classes, CLOUDSSD should be used.
The problem is how should we migrate with terraform from old storage type /instance classes to the new one?
It would be great to get more infos if anyone has any idea.
Thanks
Davide

[muneeb-jan]

Hi @deem1978

I believe this issue is more about customer success than TF services. Normally, I would suggest creating an alternate infra with new specs and migrate using a blue-green deployment strategy. However, I believe a Customer Success Engineer could guide you better through this process, providing suggestions based on your needs and current architecture.

** Please reach out to customer service or your SDM and they will refer you to the correct person. ✌️

Regards,
Muneeb

[deem1978]

Hi @muneeb-jan , thank you for your reply.
I understand what you mean and I agree completely with you, my concern is to know if from the provider side, there will be the possibility to implement a specific resource/object/solution that will support/help people to migrate from the "old" storage types to the new ones, I think that will be very helpful.
I know that on the UI side OTC will provide at some point a "Storage Migration" button, but for those who manage the infra via terraform, this would be not be very helpful, that´s the reason why I said that it would be great if from the tf provider side too, a dedicated resource could be provided.
I think that many people will be concerned with this topic in the next months (EOL of the storage types is 01.10.2026)...

[muneeb-jan]

Hi @deem1978

I don't think it would be possible to migrate in a single step. It would also depend on the type of db server. You would have to create a similar rds instance with new storage spec. Then you just need to copy the database to the new one and point all your services to the new one. Copying the database depends on the db server. Like dumping, moving and importing. However, the downtime is something to consider. Shouldn't take long though.

So, there is some TF changes to be done for this but also other processes have to follow. i am certain your SDM or support can help you through this Process much better.

[deem1978]

Yes of course, that is exactly what I will do, and I do not need any SDM or support to do it, everything is clear to me, but as I said, I was just wondering if it could be a good idea to implement something (new resource/object) on the provider side that can support the migration process, I mean something like:

resource "opentelekomcloud_rds_instance_migration_v3" "cutover" {
  source_instance_id = opentelekomcloud_rds_instance_v3.old.id

  # How to get data
  restore {
    method = "backup"          # or "pitr"
    backup_id = var.backup_id  # if method=backup
    # pitr_time = "2026-01-30T10:15:00Z" # if method=pitr
  }

  # Target specs (new)
  target {
    flavor     = "rds.mysql.n1.medium.4"
    volume_type = "CLOUDSSD"
    size_gb    = 200

    ha_mode    = "single"
    vpc_id     = var.vpc_id
    subnet_id  = var.subnet_id
    security_group_id = var.sg_id
    availability_zone = "eu-de-01"
  }

  # Strategy
  strategy {
    create_before_destroy = true
    keep_source = true          
  }

  # Cutover 
  cutover {
    enabled = var.cutover_enabled
    mode    = "endpoint"       
  }
}

output "active_endpoint" {
  value = opentelekomcloud_rds_instance_migration_v3.cutover.active_endpoint
}

I mean, this is just a trivial example, but it is just to clarify that what I am suggesting (and the related terraform specific issue) has nothing to to with any SDM or support or sale manager.... this is already clear, it would just be cool to have a terraform specific support for this specific use case.
I mean, normally when something in OTC changes (and this is the case, those are breaking changes), I think that the terraform provider should reflect/support those changes, it is not?

[muneeb-jan]

Hi @deem1978

The approach you are suggesting would be more complicated even for the clients than just creating an additional resource... and the migration logic, in this case, has to be handled in backend for it to be useful. Why?

Terraform is meant for infra provisioning and maintaining static configurations. It is declarative as in the I want this resource in this state. Only the end state matters. Migrations are procedural. Terraform have no rollback semantics which is not good for migration at all. Therefore, this has to be done outside terraform. However, the part where terraform can help is creation of target resource.

Please do note we have some parameters which allow creating an RDS from a backup but I believe this would not be helpful in your case. Terraform resources must describe steady state, not one time actions. The same way this proposed resource wouldn't work either.

Hopefully, in future, we might have some endpoints dealing with migration. We will definitely include it in terraform then.

TL:DR : Terraform works well with bringing up infra based on static configuration. Migration is a one time procedure.

[reiSh6phoo9o]

Hi, just stumbled across this topic, and I'm interested as well, because we have similar problems.

From this blogpost: "Existing instances with Common I/O will remain untouched and will be supported until they are migrated to Ultra High I/O (new name Cloud SSD) or Extreme SSD storage class.", I understand, that I can still maintain my RDS instances using terraform, even with Common IO.

From the original post I understand, that this is no longer working? That would be bad for us, because:

• we still have loads of RDS with Common IO around
• we rely on terraform for maintaining them , infrastructure wise

From the oficial OTC communication, I understand, that the EOL for common IO in RDS is postponed, because:

• OTC wants to provide a disk-migration tool, which would prevent me from having to manually migrate all my RDS instances
• but this tool is not finished yet

See here, for example: "We will first provide a disk type change feature allowing to migrate out of common IO. In addition we will prepare release of a new disk type "GP SSD v2." (…) [R]ound about mid of Q2 the storage type change feature will be given end of Q2/beginning of Q3 the GP SSD v2 will be available."

So just to be sure: can I still maintain my RDS with Common IO, using terraform? or is that broken now? As mentioned, Common IO is not yet EOL, so we still rely on it.

Thanks for clarifications!

[deem1978]

It is broken now, if you try to change anything at you RDS Instance, than you will get an error concerning instance class and storage type. I manage my instances with tf and deploy with Gitlab-CI, I struggled one week long before find the cause of those errors, because the errors were very generic...
So your instances will continue to work, but as soon as you have to change something, or if you have to manage a restore, everything, than you got errors because of instance classe and storage type.

[deem1978]

Hi @reiSh6phoo9o I just stumbled on this isse, it seems to me that the described enhancement has something to do with the topic we discussed here, is it true?