Downgrader une instance (ex B2 vers S1)

[drzraf]

Un des avantages escontés d'une offre OpenStack / public cloud est l'adaptation des performances (et du prix) aux besoins réels.

Cette évolutivité fonctionne actuellement... dans un seul sens : Nous pouvons certes créer des s1-2 et les mettre à jour vers des s1-4 ou b2 mais JAMAIS en sens inverse (à l'exception du cas particulier "b2-flex")

Nous comprenons cette restriction due aux tailles de disque différentes. Nous aimerions vivement pouvoir créer des s1-2, s1-4, ... dotées de 50GB de disque afin de pouvoir les upgrader vers du b2-7 ou r2-30 MAIS aussi les downgrader aussi aisément.

J'ai sollicité le support par le passé concernant le fait que des root-volumes (même "externals") ne pouvaient être détachés (même d'une instance stoppées) empêchant donc le contournement du problème. https://community.ovh.com/t/detacher-un-volume-persistent-bootable/28383
(Ce problème, distinct, est tout autant dommageable)

La résolution de ce problème serait pourtant triviale de la part d'OVH !
Il suffirait de nous doter de templates S1-* dotés de 50GB de disque. Ceci n'aurait aucun coût, n'implique pas de régression et ne risque nullement d'affecter les clients existants.

Permettez-nous désormais d'attendre une réponse plus concrète à ce problème récurrent et fondamental lorsqu'on parle évolutivité. (Quand on ajoute le fait que des instances stoppées continuent d'être facturées sauf à être supprimées, on se rend compte que des progrès reste à faire à ce sujet)

J'ai déjà sollicité le support de multiple fois sans recevoir de réponse autre que "transféré à R&D".
(qui est la manière polie d'OVH de répondre que "rien de concret ne sera fait")
J'espère me tromper, mais cette absence de réponse depuis des mois, me fait craindre d'y voir une mesquinerie commerciale consistant à bloquer les utilisateurs avec des ressources plus importantes que nécessaire sous peine de devoir réinstaller leur OS.

Autre situation identique :

Basculer une offre Public Cloud General Purpose B2-7 vers une offre Sandbox S1-4

[janus57]

Bonjour,

attention il y a aussi une différence de ressources entre les instances sandbox (shared) et les autres (dedicated).

Du coup contractuellement et techniquement ça doit être un poil plus complexe car si l'instance d=se fait downgrade vers un sandbox ils doivent aussi vous changer d'host.

Cordialement, janus57

[drzraf]

Contractuellement, je ne crois que ce soit un problème. Techniquement, je ne suis pas non plus certain que cela doive nécessairement impliquer un changement d'host.
Mais si tel était le cas, je pense que la fonctionnalité le vaudrait largement.

Si cela s'avérait véritablement impossible, il faudrait non seulement que OVH le dise, mais alors il s'agirait de se décider à aborder sérieusement le problème fondamental du détachement de root-volume:

Detach and attach boot volumes : Blueprints : OpenStack Compute (nova)

Auquel cas, les admins prévoyant créerait leur root sur un volume détachable et réatachable à une autre instance et l'on retrouverait la possibilité d'upgrade/downgrade.

J'aurais du mal à croire qu'OVH n'ait pas la possibilité de contribuer efficacement à de telles fonctionnalités d'OpenStack.

[janus57]

Bonjour,

Contractuellement, je ne crois que ce soit un problème. Techniquement, je ne suis pas non plus certain que cela doive nécessairement impliquer un changement d'host.

vu que d'un côté on a une instances avec des ressources garantie (Cf : CGV/CGU) et de l'autre non garantie contractuellement il faut quand même que le clients valide qu'il a connaissance que le downgrade entraine la perte de la garantie des ressources.

Et techniquement les instances avec ressources garantie ne se trouvent (normalement) pas mélangé avec des instances ou les ressources sont partagé (dans la liste des travaux cela se constate vite quand un host est down et que cela down 50 instances c'est du partagé).

Donc effectivement techniquement parlant cela n'est pas réellement impossible mais comme souvent il n'y a pas que la technique qui compte mais tout ce qui tourne autours (comme la R&D pour le process automatique).

Note : à l'origine les instances sandbox avais les même config que les VPS mais avec les avantages lié à la partie public cloud (ip-fo/vrack/snapshot et d'autres).

Cordialement, janus57

[Sich]

Comme le dit @janus57 les offres Sx sont à part dans la gamme public cloud.
Ces instances n'ont pas de ressources garanties et commercialement OVH n'a probablement pas envie que vous passiez facilement de la gamme public cloud "standard" à la gamme sandbox...

[drzraf]

OVH n'a probablement pas envie que vous passiez facilement de la gamme public cloud "standard" à la gamme sandbox...

Ce que j'appelais plus haut "mesquinerie commerciale" (... si cela s'avérait juste).

Quoiqu'il en soit, des s1-2 et s1-4 dotées de 50GB permettraient déjà des bascules indistinctement entre les 3 sandbox et ce sera déjà une première étape, celle-là très simple à mettre en œuvre.
D'ailleurs "sandbox" un terme passablement commercial lui aussi : Elles conviennent à de nombreux usages IRL.

Je continue d'attendre vivement une réponse efficace d'OVH à ce sujet. Tant le détachement de disque que le downgrade font partie du cœur de fonctionnalités attendues. Parce qu'il s'il s'agit de faire des rsync pour monter (ou descendre) en gamme, alors n'importe quel autre prestataire de VPS fait l'affaire.

[Sich]

c'est un choix commercial, c'est leur droit d'organiser leurs offres comme bon leur semble...

[ArnaudM18]

Bonjour,

C'est un choix commercial couple a un choix technique.
Chaque groupe d'instance s-, r-, b-, c- tourne sur des hyperviseurs differents.
Nous autorisons le passages des r- vers b- / c- (dans tous les sens) avec les flavors de type -flex (50G de disque).
On ne veut pas le faire pour les s-, c'est tout.

Ceci etant dit, il est possible de le faire manuellement pour vous, moyennant un snapshot de l'instance, telechargement de l'image, reduction eventuelle du filesystem, reduction de la partition, re-upload de la nouvelle image et nouveau boot. C'est complique mais pas infaisable.

Bonne journee

[drzraf]

Choix, certes, mais hautement regrettable car comme je l'évoquais plus haut, et au risque de rappeler une évidence, l'augmentation des performance à la demande ne fait sens qu'à la condition de permettre aussi leur réduction.
L'idée du snapshot, pour l'avoir déjà pratiquée, est totalement irréaliste en production: délais (de génération, downoad, upload, ...) + complexité des opérations.

La seule véritable solution qui satisferait à ce problème (et à d'autres) a déjà été évoquée ici l'an dernier :

Detach a boot volume

Il s'agit de permettre de détacher les disque (bootable) d'instances une fois stopped/shelved afin de pouvoir procéder au remplacement/substitution. De nombreux usages seraient (enfin) résolu par cette seule fonctionnalité :
- Boot disque de substitution pour backup/OS upgrade
- Redimensionnement du disque pour élargissement du filesystem
- Attache à une instance plus performante pour upgrade et downgrade