Terraform OVH - création d'un template utilisateur et installation

Bonjour @AlcorW, pouvez-vous me donner l'ID de la tâche en erreur s'il vous plaît ?

Bonjour @le_sbraz, voici le numéro de tache que je viens de lancer : 390565376
En plus de ce que je décris dans mon premier message, j'ai également l'erreur "Applying Partitioning failed" dans le manager

Merci, je vois bien une erreur pendant l'installation. Je vous contacte par MP.

EDIT : c'est résolu après avoir wipé les disques. Il y avait une erreur liée à un VG en double qui n'était pas correctement supprimé, nous avons créé un ticket pour mieux gérer ce genre de cas.

Ce partitionnement n'utiliserait pas le SoftRAID

Par curiosité, pourquoi ne pas utiliser le RAID md et utiliser LVM sur plusieurs disques/partitions ? LVM ne me semble pas forcément être le système de fichiers le plus adapté pour cette utilisation.

C'était pour éviter une techno de plus et donc potentiellement des ennuis ou des performances en retrait. Ce n'est peut-être pas la bonne logique ... je vais continuer de tester et d'apprendre. Je mettrai ici les résultats des mes tests.

Dans mon cas, je voudrais bénéficier de l'espace offert par les 2 SSD pour mes données, quitte à perdre la sécurité des données et les performances qui sont probablement meilleures en raid1. Ce qui pourrait être envisagé :
- NRAID logiciel + partitions primaires ou lvm : NRAID ne semble pas pris en charge par l'API et s'il y a un problème, les données seraient probablement plus difficiles à récupérer.
- pas de raid + partitions primaires et logiques : surement le plus facile et rapide dans mon cas mais impossible d'avoir une partition plus grande que le second SSD, ce qui peut être contraignant dans certaines utilisations.
- pas de raid + lvm : c'est ce qui me paraissait le plus pragmatique.
Quelqu'un voit d'autres solutions ?

La solution de mon premier post fonctionne pour le premier disque SSD. Pour prendre en charge le second avec LVM voici mon terraform :

terraform {
required_providers {
ovh = {
source = "ovh/ovh"
}
}
}

provider "ovh" {
endpoint = var.ovhcloud_api_endpoint
application_key = var.ovhcloud_application_key
application_secret = var.ovhcloud_application_secret
consumer_key = var.ovhcloud_consumer_key
}

resource "ovh_me_installation_template" "mytemplate" {
base_template_name = var.template_base_template_name
template_name = var.template_name
remove_default_partition_schemes = true
default_language = var.server_default_language
customization {
ssh_key_name = var.server_key_name
}
}

resource "ovh_me_installation_template_partition_scheme" "myscheme" {
template_name = ovh_me_installation_template.mytemplate.template_name
name = "myscheme"
priority = 1
}

resource "ovh_me_installation_template_partition_scheme_partition" "boot" {
template_name = ovh_me_installation_template_partition_scheme.myscheme.template_name
scheme_name = ovh_me_installation_template_partition_scheme.myscheme.name
volume_name = ""
mountpoint = "/boot"
filesystem = "ext4"
size = "1024"
order = 1
type = "primary"
}

resource "ovh_me_installation_template_partition_scheme_partition" "swap" {
template_name = ovh_me_installation_template_partition_scheme.myscheme.template_name
scheme_name = ovh_me_installation_template_partition_scheme.myscheme.name
volume_name = ""
mountpoint = "swap"
filesystem = "swap"
size = "4096"
order = 2
type = "primary"
}

resource "ovh_me_installation_template_partition_scheme_partition" "system" {
template_name = ovh_me_installation_template_partition_scheme.myscheme.template_name
scheme_name = ovh_me_installation_template_partition_scheme.myscheme.name
volume_name = "system"
mountpoint = "/"
filesystem = "xfs"
size = "25600"
order = 3
type = "lv"
}

resource "ovh_me_installation_template_partition_scheme_partition" "tmp" {
template_name = ovh_me_installation_template_partition_scheme.myscheme.template_name
scheme_name = ovh_me_installation_template_partition_scheme.myscheme.name
volume_name = "tmp"
mountpoint = "/tmp"
filesystem = "xfs"
size = "10240"
order = 4
type = "lv"
}

resource "ovh_me_installation_template_partition_scheme_partition" "varlog" {
template_name = ovh_me_installation_template_partition_scheme.myscheme.template_name
scheme_name = ovh_me_installation_template_partition_scheme.myscheme.name
volume_name = "varlog"
mountpoint = "/var/log"
filesystem = "xfs"
size = "15360"
order = 5
type = "lv"
}

resource "ovh_me_installation_template_partition_scheme_partition" "var" {
template_name = ovh_me_installation_template_partition_scheme.myscheme.template_name
scheme_name = ovh_me_installation_template_partition_scheme.myscheme.name
volume_name = "var"
mountpoint = "/var"
filesystem = "xfs"
size = "0"
order = 6
type = "lv"
}

data "ovh_dedicated_server_boots" "harddisk" {
service_name = var.server_ovhcloud_service_name
boot_type = "harddisk"
}

resource "ovh_dedicated_server_install_task" "server_install" {
service_name = var.server_ovhcloud_service_name
template_name = ovh_me_installation_template_partition_scheme.myscheme.template_name
partition_scheme_name = ovh_me_installation_template_partition_scheme.myscheme.name
bootid_on_destroy = data.ovh_dedicated_server_boots.harddisk.result[0]
details {
custom_hostname = var.server_hostname
no_raid = true
disk_group_id = 1
}
}

resource "null_resource" "lvm_extend_var" {
depends_on = [ovh_dedicated_server_install_task.server_install]

connection {
type = "ssh"
host = var.server_hostname
user = var.server_user
private_key = file("${var.local_key_path}${var.server_key_name}")
}

provisioner "remote-exec" {
inline = [
"sudo pvcreate /dev/sdb",
"sudo vgextend vg /dev/sdb",
"sudo lvextend -l +100%FREE /dev/vg/var",
"sudo xfs_growfs /dev/mapper/vg-var",
]
}
}

Quelques remarques cependant :
- ce script fonctionne actuellement avec Terraform 1.7.0 et le provider ovh/ovh 0.36.1 ; attention également à l'évolution de l'API OVH.
- J'ai choisi XFS, réputé plus rapide que ext4 mais avec l'inconvénient de ne pas avoir d'outil pour réduire la taille d'une partition. Ça peut être ennuyeux si vous avez mal calculé vos espaces disques dès le départ. Si vous utilisez ext4, il faut remplacer la dernière ligne du remote-exec (xfs_growfs par la commande équivalente resize2fs).
- en cas de panne d'un disque, LVM est un facteur aggravant pour la récupération de vos données sur l'autre disque. Ce n'est pas le cas avec un partitionnement classique. Faites des backups automatisés !
- Le script fonctionne avec un user qui est sudoer en NOPASSWD, c'est le cas de l'utilisateur "ubuntu" par défaut sur la version OVH de Ubuntu Server 22.04 64 bits.
- Vraisemblablement, un bug du cloud OVH ne permet actuellement pas d'effacer correctement une telle configuration lors d'une réinstallation. Tant qu'il persiste, il faut booter en rescue et supprimer les partitions manuellement (avec fdisk ou sinon dd if=/dev/zero of=/dev/sdb puis sda ou encore wipefs -af /dev/sdb puis sda)
- Pour que ce script fonctionne il vous faudra créer un fichier de déclaration des variables utilisées et un fichier de renseignement des valeurs des variables.
Je ne pense pas faire d'autres essais.
Merci à @le_sbraz

> - Vraisemblablement, un bug du cloud OVH ne permet actuellement pas d'effacer correctement une telle configuration lors d'une réinstallation. Tant qu'il persiste, il faut booter en rescue et supprimer les partitions manuellement (avec fdisk ou sinon j'ai fait des dd if=/dev/zero of=/dev/sda puis /dev/sdb)

Normalement, un `wipefs -af /dev/sdb` devrait suffire car il effacera la signature LVM du disque.

Le ticket lié au bug a bien été créé et il semble que le problème soit l'utilisation du flag `no_raid`. Lorsque celui-ci est actif, le second disque de la grappe n'est pas effacé. Pouvez-vous essayer en enlevant `no_raid = true` et en mettant plutôt `soft_raid_devices = 1 ` ? Cela devrait permettre l'effacement du second disques même si le premier disque sera le seul à être partitionné.

Merci pour la commande wipefs.
En reprenant mon script de départ et en remplaçant no_raid ... par soft_raid_devices = 1, j'obtiens l'erreur suivante :
> Error: Error waiting for Dedicated Server task xxxxxxxxx.eu/0 to complete: OVHcloud API error (status code 404): \"The requested object (taskId = 0) does not exist\" (X-OVH-Query-Id: EU.ext-xxxxxxxxx)

Au préalable j'ai wipé mes ssd (vérifié), mon registry terraform est vidé et j'ai également supprimé le template custom.

Bonjour,
Désolé de relancer @le_sbraz, j'ai dû réinstaller mon serveur pour l'utiliser et je ne peux plus faire de test mais mon dernier test (https://community.ovhcloud.com/community/fr/terraform-ovh-creation-d-un-template-utilisateur-et-installation?id=community_question&sys_id=8a24d0dcf59e86d02d4c5f7a9ab3617e?u=alcorw) reste valable et aurait tendance à confirmer un bug tout de même. Si **no_raid** est peut-être la raison du problème, **soft_raid_devices** n'est pas la solution pour autant.

Rebonjour,
J'ai raté votre message du 24, il y a dû avoir un autre problème empêchant la tâche d'installation de se créer quand vous avez utilisé `soft_raid_devices` car je ne vois dans les log du serveur aucune tâche avec ce paramètre à 1. Ça expliquerait le message d'erreur suivant où la tâche avec l'ID 0 n'existe pas.

Je vais voir si je retrouve les logs de démarrage d'installation pour vous en dire plus.

EDIT : je ne retrouve pas l'erreur exacte dans les logs. Si jamais vous avez la possibilité de refaire des tests sur ce serveur ou un autre, n'hésitez pas à remonter le problème, l'idéal serait d'avoir les headers `X-OVH-Query-Id` pour la requête qui ne passe pas.

J'ai un deuxième serveur que je dois terminer de migrer prochainement mais il est disponible dans le manager kimsufi, je ne suis pas sûr que l'API OVH puisse le gérer.

Normalement l'API Kimsufi présente les mêmes routes que celles d'OVH. À première vue, le provider Terraform le supporte : https://github.com/ovh/terraform-provider-ovh/blob/dbabaf384c972971b1fd49b35e7bb92062c1cbcb/ovh/config.go#L110