feat/ceph_validate_health #121

						
				@ -0,0 +43,4 @@

				        topology: &T,

				    ) -> Result<Outcome, InterpretError> {

				        let client = topology.k8s_client().await.unwrap();

				        self.verify_ceph_toolbox_exists(client.clone()).await?;

johnride commented

2025-08-25 18:45:19 +00:00

Ca me fait penser, et d'ailleurs ça intéressera @letian :

Je pense qu'on peut set du contexte dans le thread d'exécution Tokio. Ça pourrait être utile pour l'instrumentation.

Pourquoi j'y pense ici c'est qu'on pourrait transformer verify_ceph_toolbox en ensure_ceph_toolbox et lancer le score qui s'occupe de la lever. Cote UX actuellement on voit des logs apparaitre, et cote code nous on n'a pas la trace de qui a parti ca pourquoi. Mais en injectant du "metadata" dans le thread on pourrait faire en sorte qu'un score qui s'execute par une nouvelle task qui a un execution context qui a l'info suffisante pour de la bonne instrumentation (genre, c'est qui mon parent).

Just food for thought.

Ca me fait penser, et d'ailleurs ça intéressera @letian : Je pense qu'on peut set du contexte dans le thread d'exécution Tokio. Ça pourrait être utile pour l'instrumentation. Pourquoi j'y pense ici c'est qu'on pourrait transformer `verify_ceph_toolbox` en `ensure_ceph_toolbox` et lancer le score qui s'occupe de la lever. Cote UX actuellement on voit des logs apparaitre, et cote code nous on n'a pas la trace de qui a parti ca pourquoi. Mais en injectant du "metadata" dans le thread on pourrait faire en sorte qu'un score qui s'execute par une nouvelle task qui a un execution context qui a l'info suffisante pour de la bonne instrumentation (genre, c'est qui mon parent). Just food for thought.