Optimisation du contrôleur Sedna d'inférence conjointe et d'apprentissage fédéré v1.1

Quand l'apprentissage fédéré change la config en éditant la ressource custom (kubectl edit FederatedLearningJob **), le chemin de mise à jour est qu'un pod ne peut pas mettre à jour ses paramètres sur place comme un Deployment de la ressource d'inférence conjointe (voir cet issue et ce billet). Donc il ne restait qu'à supprimer tous les pods (parce qu'on ne pouvait pas en récupérer un seul) et les recréer avec la nouvelle config. Dans le contrôleur d'inférence conjointe, le nom du deployment est fixe à la création, donc on peut

Deployment, err := c.deploymentsLister.Deployments(service.Namespace).Get(workerName)

récupérer ce deployment, changer les paramètres et mettre à jour. Mais aujourd'hui le nom généré du pod a 5 caractères aléatoires à la fin, donc on ne peut pas le retrouver par nom. J'ai aussi vu que le nommage dans le contrôleur ne marche pas (ce code) :

"WORKER_NAME": "aggworker-" + utilrand.String(5)

Cette ligne ne fait rien, donc c'est kubernetes qui nomme le pod tout seul.

La cause : dans injectWorkerParam de pkg/globalmanager/runtime/worker.go, pod.ObjectMeta.Name n'est jamais assigné. Je pense qu'il faut

pod.ObjectMeta.Name = workerParam.Env["WORKER_NAME"]

Ensuite on peut fixer le nom du pod en changeant "WORKER_NAME". Une fois le nom connu, et une fois qu'on sait quel champ de quel worker de la ressource custom a changé, on peut supprimer ce pod et le recréer, sans tout effacer.

Plus tard, Tang Ming a dit que, contrairement à l'inférence, une tâche d'entraînement fédéré, c'est essentiellement un Job kubernetes. Un Job est one-shot, donc autant interdire la modification : si on veut changer les paramètres, on supprime et on redéploie. Je trouve ça raisonnable. En plus, un pod ne se met pas à jour, donc cette approche va un peu contre l'intention de kubernetes… Le prochain objectif est donc de restreindre l'accès à la ressource. Je rassemble encore des matériaux…

Par rapport à la version Open Source Promotion Plan, ce sont de petits changements, donc v1.1. La suite sera v2 parce que l'idée diverge de v1. Donc pas de PR non plus.