|
| 1 | +--- |
| 2 | +page_title: "Migrating dedicated servers from previous versions to v2.0.0" |
| 3 | +--- |
| 4 | + |
| 5 | +Version v2.0.0 of OVHcloud Terraform provider introduced a breaking change on the resources related to dedicated servers, mainly: |
| 6 | +- Deletion of resource `ovh_dedicated_server_install_task` that has been replaced by a new resource `ovh_dedicated_server_reinstall_task` |
| 7 | +- The parameters of resource `ovh_dedicated_server` have been updated to reflect the changes on parameters needed to reinstall a dedicated server |
| 8 | + |
| 9 | +The complete changelog can be found [here](https://github.com/ovh/terraform-provider-ovh/releases/tag/v2.0.0). |
| 10 | + |
| 11 | +This guide explains how to migrate your existing configuration relying on resource `ovh_dedicated_server_install_task` to a new configuration compatible with version v2.0.0 of the provider without triggering a reinstallation of your dedicated servers. |
| 12 | + |
| 13 | +!> This documentation presents a direct migration path between v1.6.0 and v2.0.0. To make this transition easier, we released a version v1.7.0 of the provider that includes both deprecated resources and the new ones. The migration steps are the same, but this version allows a more gradual shift towards v2.0.0. |
| 14 | + |
| 15 | +## First step: import your dedicated servers in the state |
| 16 | + |
| 17 | +From version v2.0.0 and later, the preferred way to manage dedicated servers installation details is through usage of resource `ovh_dedicated_server`. As a result, if you don't already have your dedicated servers declared in your Terraform configuration, you must import them. |
| 18 | + |
| 19 | +You can use an `import` block like the following: |
| 20 | + |
| 21 | +```terraform |
| 22 | +import { |
| 23 | + id = "nsxxxxxxx.ip-xx-xx-xx.eu" |
| 24 | + to = ovh_dedicated_server.srv |
| 25 | +} |
| 26 | +
|
| 27 | +resource "ovh_dedicated_server" "srv" {} |
| 28 | +``` |
| 29 | + |
| 30 | +-> If you are doing a first migration to v1.7.0, you should add the following parameter `prevent_install_on_import = true` to the dedicated server resource. This guarantees you that the server won't be reinstalled after import, even if you have a diff on the reinstall-related parameters. |
| 31 | + |
| 32 | +To finish importing the resource into your Terraform state, you should run: |
| 33 | + |
| 34 | +```sh |
| 35 | +terraform apply |
| 36 | +``` |
| 37 | + |
| 38 | +## Second step: backport your previous task details into the imported resource |
| 39 | + |
| 40 | +This step is manual and requires you to convert the previous installation details from resource `ovh_dedicated_server_install_task` to the new fields of resource `ovh_dedicated_server`: `os`, `customizations`, `properties` and `storage`. |
| 41 | + |
| 42 | +Let's take an example: if you previously used the following configuration: |
| 43 | + |
| 44 | +```terraform |
| 45 | +resource "ovh_dedicated_server_install_task" "server_install" { |
| 46 | + service_name = "nsxxxxxxx.ip-xx-xx-xx.eu" |
| 47 | + template_name = "debian12_64" |
| 48 | + details { |
| 49 | + custom_hostname = "mytest" |
| 50 | + } |
| 51 | + user_metadata { |
| 52 | + key = "sshKey" |
| 53 | + value = "ssh-ed25519 AAAAC3..." |
| 54 | + } |
| 55 | + user_metadata { |
| 56 | + key = "postInstallationScript" |
| 57 | + value = <<-EOF |
| 58 | + #!/bin/bash |
| 59 | + echo "coucou postInstallationScript" > /opt/coucou |
| 60 | + cat /etc/machine-id >> /opt/coucou |
| 61 | + date "+%Y-%m-%d %H:%M:%S" --utc >> /opt/coucou |
| 62 | + EOF |
| 63 | + } |
| 64 | +} |
| 65 | +``` |
| 66 | + |
| 67 | +You can replace it by the following one: |
| 68 | + |
| 69 | +```terraform |
| 70 | +resource "ovh_dedicated_server" "srv" { |
| 71 | + customizations = { |
| 72 | + hostname = "mytest" |
| 73 | + post_installation_script = "IyEvYmluL2Jhc2gKZWNobyAiY291Y291IHBvc3RJbnN0YWxsYXRpb25TY3JpcHQiID4gL29wdC9jb3Vjb3UKY2F0IC9ldGMvbWFjaGluZS1pZCAgPj4gL29wdC9jb3Vjb3UKZGF0ZSAiKyVZLSVtLSVkICVIOiVNOiVTIiAtLXV0YyA+PiAvb3B0L2NvdWNvdQo=" |
| 74 | + ssh_key = "ssh-ed25519 AAAAC3..." |
| 75 | + } |
| 76 | + os = "debian12_64" |
| 77 | + properties = null |
| 78 | + storage = null |
| 79 | +} |
| 80 | +``` |
| 81 | + |
| 82 | +You can check the documentation of resource `ovh_dedicated_server` to see what inputs are available for the reinstallation-related fields. |
| 83 | +The documentation of resource `ovh_dedicated_server_reinstall_task` also includes several examples of configuration. |
| 84 | + |
| 85 | +## Third step: make sure your server is not reinstalled unintentionally |
| 86 | + |
| 87 | +You should add the following piece of configuration in the declaration of your dedicated server resource in order to avoid a reinstallation on the next `terraform apply`: |
| 88 | + |
| 89 | +```terraform |
| 90 | +resource "ovh_dedicated_server" "srv" { |
| 91 | + # |
| 92 | + # ... resource fields |
| 93 | + # |
| 94 | +
|
| 95 | + lifecycle { |
| 96 | + ignore_changes = [os, customizations, properties, storage] |
| 97 | + } |
| 98 | +} |
| 99 | +``` |
| 100 | + |
| 101 | +This is needed because there is no API endpoint that returns the previous installation parameters of a dedicated server. The goal here is to migrate your old configuration to the new format without triggering a reinstallation. |
| 102 | + |
| 103 | +## Fourth step: remove the lifecycle block |
| 104 | + |
| 105 | +After a while, whenever you need to trigger a reinstallation of your dedicated server, you can just remove the `lifecycle` field from your configuration and run `terraform apply`. |
0 commit comments