Etat du Zéphir

date:2018-10-11

Gestion des groupes et des droits

  • une base user sera nécessaire pour stocker des données métier
  • définir une stratégie de gestion des droits
  • si un utilisateur est créé dans keycloack, le zephir devra le savoir

Analyse des messages

l’objectif est de prendre la mesure de ce qui a été fait

message privés / messages publics

  • côté UI : que du RPC
  • broadcast : événement
  • possiblité de s’inscrire à une liste d’événements ?

Important

tous les messages vers l’extérieur sont de type RPC

(retour d’une demande de l’utilisateur, puis exécution, puis par exemple retour de l’id du job)

description des messages

messages spécifiques à un domaine.

exemple :

config execution

n’importe quel domaine peut s’inscrire auprès de n’importe quel micro service

un domaine <-> un service

limiter au niveau de crossbar l’ins

Les messages de configuration

config.session.server

  • messages de sessions gen_config

    • id de session (classé par id)
    • une configuration d’un serveur

  • on ne peut travailler sur la configuration qu’à travers le gen_config

  • les valeurs définies ne renvoient que les valeurs qui sont saisissables

  • sur la partie config, il va manquer un équivalent CreoleGet, CreoleSet

identify.settings.get

  • données du cookies dans les messages : pour l’instant l’interface a besoin du nom de l’utilisateur connecté. Il faut aller le demander à keycloak. Pareil pour tous les settings.

Messages de type server

  • server.describe

  • server.describe

  • Messages de type execute

    • server.exec.deploy : déploiement de la configuration
    • server. exec.peer-connection: message d’appairage

Messages de type servermodel

un servermodel est une variante

Important

aujourd’hui, on ne peut pas mettre à jour un ServerModel

subrelease:c’est la version

Important

les zones ne sont pas implémentées. On ne sait pas comment on va faire.

Points restant à élucider

  • Mapping entre le domaine et le microservice

    Dans les messages listés, le domaine correspond.

    Pour server.delete par exemple, quel sont le (les) message(s), et quels sont les microservices concernés ?

    Les messages automatiques, exemple : pour un server.delete un message de retour est automatiquement renvoyé.

    (la notification automatique est faite à l’aide d’un décorateur)

  • Conception d’architecture :

    Faut-il déporter dans un service externe la validation par contrat des messages, les ramener dans les contrôleurs, ou bien un microservice à part pour la validation des messages ? Il y a plusieurs façon de faire, si l’api-gateway ne tient pas la charge, alors on repense l’architecture. A noter que l’api-bridge est scalable.

    On est dans le « backend du frontend », il faut que l’api-gateway réponde rapidement. idée : mettre l’authentification dans l’api-bridge.

Manques

  • La documentation développeur est à étoffer et à mettre en lien avec le code.

    (exemple : explications sur le code des décorateurs permettant de valider l’API à partir des contrats yaml.

La fake UI en retard par rapport au backend.

  • La question des tests fonctionnels automatisés se pose.

Questions

  • Comment dialogue-t-on avec salt ?
  • Comment inclure/lier l’EAD3 avec le zephir ?
  • Quel niveau de communication doit-on avoir avec les deux applications ?

Avec un id de session, on pourrait accéder directement à l’EAD3. Pour les actions groupées, se baser massivement sur salt.

La question d’un master (« zéphir établissement ») au niveau des serveur établissement se posera seulement si il est impossible de faire des actions groupées.

  • Est-ce que le nebula correspond aux besoins du développeur ???
  • les ressources de qualif et de dev ne devraient pas être concurrentielles.

Roadmap

  • L’UI semble être en retard par rapport au commandes possibles et aux messages du backend.

    On peut simplifier nos exigences sur l’UI de manière à se ramener aux cas d’usage d’un administrateur zephir. L’ui peut être reportée dans une version suivante.

  • Ce qu’il reste à faire

    • beaucoup de polissage
    • le pipeline d’intégration continue (sachant que le pipeline n’est pas obligatoire)
    • l’automatisation peut-être faite après.
    • les tests fonctionnels automatisés sont contenus dans la néthode
    • le process peut être délivré en parallèle
    • la question de la gestion du code source (pull request)

  • travail sur l’organisation : le scrum tel qu’on l’applique est handicapant. (scrumban (scrum-kanban)?)

Tâches

  • ajouter une tâche d’évaluation tornadocherry-py (dans un scénario du sprint)
  • avoir la maîtrise de tous nos conteneurs (notamment postgres), afin de maitriser la montée de version

Usage de SaltStack

  • utilisations ésotériques : on se plugge sur le bus d’événement de salt

  • on ne fait que des run

  • et écouter le bus d’évènements (websockets)

  • un microservice qui fait toute l’interface :

    • Saltmaster-manager
    • Salt-api
    • Saltmaster

Usage de SaltStack

  • utilisations ésotériques : on se plugge sur le bus d’événement de salt

  • on ne fait que des run

  • et écouter le bus d’évènements (websockets)

  • un microservice qui fait toute l’interface :

    • Saltmaster-manager
    • Salt-api
    • Saltmaster

Note

Faudra-t-il passer par crossbar ou bien directement un appel à salt ? Au niveau des droits, le message à passer à salt doit être « final » : « execute cette commande sur cette liste de serveurs » et pas « exécute cette commande sur la liste de serveurs de l’utilisateur toto »