Elastic Metal : un refus qui cite le client absent, et ce client est en train d'arriver

[stephrobert]

Deux refus d'Elastic Metal nomment le client qui les lèverait, et l'un d'eux cite
la collection Ansible par son nom.

Le refus qui se cite lui-même

emulator.Because("it reads one server by identifier, its events or its metrics,
  and the measured clients never do: an inventory enumerates (the
  stephrobert.scaleway plugin's own comment says it never reads one by one) …",
    "baremetal/v1/API.GetServer",
    …)

La raison est exacte aujourd'hui, et elle repose entièrement sur une
propriété du client. Mesuré dans leur dépôt le 14 septembre 2026 :

ls plugins/modules | grep -c '^baremetal'   -> 0   sur 69 modules
ls plugins/module_utils/inventory/providers/
  -> instance.py   elastic_metal.py   apple_silicon.py

L'inventaire découvre trois familles de machines. Leur rôle rolling_reboot
n'appelle que instance_server_action et instance_server_info : un parc mixte
est donc découvert en entier et redémarré à moitié.

Un baremetal_server_info qui lit par identifiant serait précisément le client
que cette raison déclare absent (leur #255).

L'autre refus, et pourquoi il est plus solide

emulator.Because("it acts on the hardware behind a server — an install writes an
  OS to its disks, a reboot, a start and a stop cycle its power … and there is no
  hardware behind a seeded server for any of that to happen to",
    "baremetal/v1/API.RebootServer", …)

Celui-là ne tombe pas avec un client. Il pose une question réelle : un serveur
semé n'a pas de matériel derrière lui.

Mais l'émulateur rend déjà les transitions d'Instance immédiates en --vm off
(docs/limits.md, « Lifecycle transitions are immediate »), et machine.Binding
existe pour que la séquence soit la même d'un pack à l'autre. La question est
ouverte, pas tranchée : un RebootServer qui fait passer l'état et ne prétend
rien du matériel serait-il un mensonge, ou la même honnêteté que pour une
Instance ?

Ce qui est proposé, et ce qui ne l'est pas

Proposé : les lectures par identifiant, GetServer et ListServerEvents,
dont le refus nomme son propre client.

À décider : RebootServer, StartServer, StopServer, sur la question
ci-dessus.

Pas proposé : GetServerMetrics. feint n'a aucune télémétrie à rendre
honnêtement, et l'inventer serait exactement ce que les deux dépôts refusent.

Le coût de la preuve, et c'est le plus élevé

docs/limits.md le dit : commander un Elastic Metal est « a paid commitment on
hardware the cloud delivers in minutes to hours ». Incompatible avec une stack à
résidu zéro jouée à chaque run.

Deux chemins, dans cet ordre :

1. Preuve émulée d'abord, sur état semé (PUT /_feint/state, format décrit
   dans docs/limits.md). ListServers et ListOffers sont déjà servis comme
   ça.
2. Preuve réelle une seule fois, par transcription enregistrée, s'il existe un
   serveur à lire. Jamais à chaque run.

Ce qui reste à vérifier

Si leur inventaire lit déjà GetServer par identifiant quelque part, le refus
est déjà faux aujourd'hui plutôt que demain. Leur commentaire dit le contraire,
et c'est ce commentaire que le refus cite : une mesure vaudrait mieux que deux
commentaires qui se renvoient l'un à l'autre.

---

Relevé par un audit croisé des deux dépôts. Contrepartie ouverte chez eux :
stephrobert/collection-scaleway#255.