Vérifier et publier

Ce que Core dit au chargement

Chaque défaut a une gravité, et la gravité décide de ce que voit la personne.

gravité	effet	exemple
error	la station refuse de démarrer	un appel du submit dont le tool ne nomme aucune opération ; deux skills sur le même kind
withhold	cette skill n'est pas exposée ; le reste sert	une skill dont l'invoke nomme une capability qui n'existe pas
note	écrit pour l'auteur ; rien ne change	un playbook qu'aucune skill n'ouvre

Quelques refus utiles à connaître :

écrit	refusé parce que
une garde update: {price: …} sans que le submit transmette $item.price	le client verrait un prix que le tenant ne reçoit jamais
une condition (require, when) mal écrite, ou qui lit un champ non déclaré	un require qui ne lit rien refuserait tous les items
$item.id dans un champ d'idempotence	voir Le submit
un $submitted[…] qui cite un appel qu'aucune tâche de playbook ne fait, ou une sortie non déclarée	il serait vide, et le tenant recevrait un blanc avec ok: true ; voir Le submit
deux appels dans un même submit	une nouvelle tentative après l'échec du second renverrait le premier
une tâche required dont la skill ne produit aucun kind	le parcours annoncerait « prêt » sur une sélection vide
une tâche qui n'est pas exactement une de skill, one_of, all_of ; un one_of de moins de deux méthodes, ou sans méthode sans when ; deux méthodes qui prennent le même kind	on ne saurait pas ce que fait la tâche, ni de quelle méthode est une ligne ; voir Playbooks
un when de tâche ou de méthode qui lit autre chose que $selection.kinds, cherche un kind que la station n'a pas, ou un kind de sa propre tâche (pour un all_of, des tâches qu'il joint)	la condition ne pourrait pas être vérifiée, ne tiendrait jamais, ou fermerait la tâche pour toujours
une skill dans deux tâches d'un playbook	une ligne ne dirait pas de quelle tâche elle est
un after ou un all_of qui nomme une tâche absente ou une tâche sans kind, ou qui boucle ; un all_of sur des tâches ordonnées entre elles	la tâche ne s'ouvrirait jamais
une tâche requise after une tâche facultative, directement ou par un all_of	la tâche facultative serait requise en fait
present, select, submit, countable, depends_on ou on_loss sur une skill sans kinds	ses lignes ne sont pas des items : rien ne lirait ces clés
plusieurs kinds dont un sans when ; un when de kind qui lit autre chose qu'un champ de present.fields ($fields.<nom>)	rien ne dirait de quel kind est une ligne ; une clé de ligne non déclarée n'est jamais lue
invoke avec method et native, ou aucun des deux ; method: search_products	method nomme une opération des APIs de la station ; les capabilities de Convoy s'écrivent native
un $params.x non déclaré, un paramètre que rien ne lit, un argument de invoke.args que la capability ne prend pas	un paramètre que rien ne fixe ou que rien ne lit tromperait le lecteur ; l'API ignorerait un argument inconnu et répondrait comme s'il n'avait pas été envoyé
un paramètre sans default lu par invoke.args, ou qu'aucune tâche ne lie ; des params de tâche qui ne lient pas $submitted[<tâche>.<appel>].<sortie> d'une autre tâche du playbook, jamais sautée, dont chaque méthode fait l'appel	l'appel partirait avec une valeur vide ; voir Playbooks
un render.component inconnu	une faute de frappe dessinerait autre chose, en silence
component: report sans render.report	rien ne dit quel champ est la réponse : la personne lirait du texte au lieu du rapport
render.report avec un autre composant que report	rien ne le lirait
deux skills ou deux playbooks du même name	le second remplacerait le premier, sans un mot
un submit_guard.validate qui ne nomme aucune opération	aucun submit ne pourrait aboutir
catalog.mode: indexed sans search_text_fields	chaque ligne serait indexée sur un texte vide
une clé que Core ne connaît pas, à n'importe quelle profondeur	elle ferait croire qu'elle a un effet ; l'API du provisioner répond 422 avec unknown_keys

Les tests

# les exemples de ce guide, compilés par Core
pytest convoy/packages/convoy-core/tests/test_docs_examples.py

# une station qui tourne : les sondes rejouent des défauts qui ont vraiment été livrés
./scripts/readiness/all.sh

Publier

• Fichier : déposer <tenant_id>.yaml dans le dossier de configs du déploiement.
• API : le provisioner fait d'abord la même vérification que la station. Une config qui a une error reçoit un 422 avec la liste des défauts (where, message, remedy), et rien n'est écrit. Sinon il écrit la config en base et démarre les conteneurs du tenant. Il répond ready seulement quand chaque serveur sert ce tenant : le MCP a sa config et expose les skills que Core compile, l'agent a son historique. Sinon le tenant est degraded, et la réponse (502) dit pourquoi.

Entre deux changements, le provisioner regarde chaque station ready toutes les minutes. Si un serveur s'arrête ou ne sert plus la station, elle passe à degraded ; quand il sert de nouveau, elle revient à ready. Chaque passage laisse une trace dans le journal (/runs).

Dans les deux cas, la station recompile au démarrage et affiche chaque erreur et chaque note. Lisez les notes.

Mettre à jour une station

POST /v1/tenants/{id}/redeploy, sans corps, remet la station sur le Core et les images du provisioner, avec la config qu'elle a déjà. Si ce Core refuse maintenant la config, la réponse est un 422 avec les défauts, et aucun serveur n'est touché. Pour toute la flotte : make stations-build puis make stations-redeploy.

Une station ne tourne que sur des images construites avec le même Core que le provisioner. Sinon, le changement reçoit un 409 core mismatch, et rien n'est modifié.

Pour revenir à une config qui marchait : GET /v1/tenants/{id}/versions liste les dix dernières versions, et POST /v1/tenants/{id}/rollback avec {"version": n} réapplique la config de cette version.

Pour savoir d'avance quelles stations seraient refusées : python -m convoy_provisioner.admin check-configs donne le verdict de chaque station, et le provisioner le dit aussi dans son journal au démarrage.

Pour savoir si une station tourne encore avec le fichier de son auteur : POST /v1/tenants/{id}/compare avec la config répond same et la liste des clés qui diffèrent, sans rien changer.

Retirer

DELETE /v1/tenants/{id} passe le tenant à deleting, puis retire ses serveurs, sa config et sa route. Pendant ce temps, tout changement reçoit un 409. Si une étape échoue, la réponse (502) dit ce qui est déjà retiré : renvoyer le même DELETE termine le travail. Le journal (/runs) reste en base après la suppression, pour savoir qui a retiré quoi.

Deux changements sur le même tenant ne se font jamais en même temps : le second reçoit tout de suite un 409 busy. Il suffit de le renvoyer quand le premier est fini.