search

petalslink / petals-cockpit-specs

Specifications for Petals Cockpit
https://petals.gitbook.io/petals-cockpit-specs
GNU General Public License v2.0
1 stars 1 forks source link

Hiérarchie & pages #13

Open psouquet opened 5 years ago

psouquet commented 5 years ago

Je lance ici la conversation sur la hiérachie et la liste des pages de petals cockpit. En lien avec la liste des cas d'usages qui seront mis à jours après cette issue.

Originally posted by @vincent-zurczak in https://github.com/petalslink/petals-cockpit-specs/issues/12#issuecomment-474966879

C'est amusant, parce que c'est le genre de questions auxquelles répond un arbre des tâches. :speak_no_evil:

A graph attempt

digraph G {

    style=filled;
    color=lightgrey;
    node [style=filled,color=white];
    a0 [label="Accueil / Sélection des espaces de travail"]
    a1 [label="Espace de travail"]
    a2 [label="Topologies"]
    a3 [label="Conteneur"]
    a15 [label="Registre"]
    a4 [label="Services"]
    a0 -> a1;
    a1 -> a2;
    a2 -> a3;
    a2 -> a15;
    a2 -> a4;

    a5 [label="Composants"]
    a55 [label="<Composant> ?"]
    a6 [label="Service Units"]
    a66 [label="<su> ?"]
    a7 [label="Service Assemblies"]
    a77 [label="<sa> ?"]
    a8 [label="Shared Libraries"]
    a88 [label="<sl> ?"]
    a10 [label="admin"]
    a3 -> a10 [style=dashed];
    a3 -> a5; a5 -> a55 [style=dashed];
    a3 -> a6; a6 -> a66 [style=dashed];
    a3 -> a7; a7 -> a77 [style=dashed];
    a3 -> a8; a8 -> a88 [style=dashed];

    a9 [label="Services (vue transverse)"]
    a1 -> a9;
}

Pour info, j'ai utilisé cet éditeur pour créer le graphe, et ce site pour l'encoder dans l'URL. L'arbre est un peu fait à l'arrache, je n'ai pas tout précisé. Faîtes simple, considérez la SU comme une SA ou une SL. Tout est au niveau du conteneur. Inutile de rendre les choses plus compliquées pour l'utilisateur... :roll_eyes:

URL Fil d'Ariane Commentaire
/dev/t Dev > Topologies Liste de toutes les topologies dans l'espace dev.
/dev/t/ma%20topologie Dev > ma topologie Accès à une topologie.
/dev/t/ma%20topologie/c Dev > ma topologie > Containers La liste des conteneurs dans cette topologie.
/dev/t/ma%20topologie/c/bus-0 Dev > ma topologie > Bus-0 Les informations et l'administration de Bus-0.
/dev/t/ma%20topologie/r Dev > ma topologie > Containers La liste des registres dans cette topologie.
/dev/t/ma%20topologie/s Dev > ma topologie > Services La liste des services dans cette topologie.

Dans ce tableau, les listes ne sont pas accessibles directement dans le fil d'Ariane. Mais le but du fil est de savoir où on est, pas forcément d'avoir accès à tous les liens possibles.

En fait, les vraies questions qui se posent, c'est de savoir quels niveaux se déclinent en pages. Est-ce qu'on veut une page dédiée pour une service unit ? Est-ce que ça a un sens ? Ou bien est-ce qu'une liste avec une vue détaillée suffit ? De même, est-ce qu'on fait une page dédiée pour les actions d'administration sur un conteneur ? Ou bien est-ce que la page d'accueil du bus suffit ? Elle contiendrait alors les options d'administrations et des liens vers les différentes listes d'artefacts.

Autres questions posées par le tableau que je viens de créer : est-ce que le nom autorise les espaces ? Est-ce que les alias ou la casse sont acceptés ? Ma topologie est-elle équivalente à ma topologie et ma-topologie ? J'aurais tendance à dire oui, et que c'est une contrainte à poser. Et cela aura des répercussions dans Petals (parseur de topologie, server.properties, librairie de déploiement) et dans le back-end de Cockpit (base de données, vérifications).

psouquet commented 5 years ago

Originally posted by @bescudie in https://github.com/petalslink/petals-cockpit-specs/issues/12#issuecomment-475197102

J'ai refait l'arbre des pages: image

Le fil d'ariane n'est présent que dans les pages Espaces de travail, car Admin PetalsCokpit et User sont des "Dialog" Pour le Fil d'Ariane cela donne:

URL Fil d'Ariane Commentaire
/W=idWksp Dev Page générale du workspace "Dev" id="idWksp", description...
/W=idWksp /T/B=idBus Dev>Topologie> nameBus Page du Bus id="idBus" et nom="nameBus" dans le wkspce "Dev"
/W=idWksp /T/B=idBus/C=idCont Dev>Topologie> nameBus>nameCont Page Container id="idCont" et nom="nameCont" du bus idBus dans le wkspce "Dev"
/W=idWksp /T/B=idBus/C=idCont/cp=idComp Dev>Topologie> nameBus>nameCont>nameComp Page Composant id="idComp" et nom="nameComp" du container idCont du bus idBus dans le wkspce "Dev"
/W=idWksp /T/B=idBus/C=idCont/sa=idSA Dev>Topologie> nameBus>nameCont> nameSA Page de la SA id="idSA" et nom="nameSA" du container idCont du bus idBus dans le wkspce "Dev"
/W=idWksp /T/B=idBus/C=idCont/cp=idComp/su=idSU Dev>Topologie> nameBus>nameCont> nameComp>nameSU Page de la SU id="idSU" et nom="nameSU" sur le composant idComp du container idCont du bus idBus dans le wkspce "Dev"
... ... ...
/W=idWksp /S/I=idInterface Dev>Service> nameInterface Page de l'Interface de Service id="idInterface" et nom="nameInterface" dans le wkspce "Dev"
... ... ...
psouquet commented 5 years ago

Originally posted by @vincent-zurczak in https://github.com/petalslink/petals-cockpit-specs/issues/12#issuecomment-475201061

Dans la vue qui affiche tout (disons l'explorateur), il est intéressant que les SU apparaissent sous les composants (c'est une vue logique). Mais dans le cadre de la gestion des artefacts, ça oblige à connaître le composant avant d'accéder à une SU. Et si l'utilisateur ne sait pas à quel composant elle est rattachée ? Ou s'il veut une vue globale de toutes les SU (rien que les SU) ?

Plus globalement, la SU associée au composant, c'est comme ça que c'est fait dans Petals, parce que ça vient de JBI. Mais chez les ESB concurrents, tout est au même niveau. Et tous ont un équivalent des SU et des SA. Avoir les deux accès (par le composant ou depuis le conteneur) serait donc préférable. En gros, SU et Composants seraient côte-à-côte, et il y aurait une flèche qui va de Composants vers SU.

Pour le fil d'Ariane.... nameCont> nameComp>nameSU laisse penser que l'ID de la SU est propre au composant, alors que dans Petals, cet ID est unique sur le conteneur (le composant ne vérifie rien de mémoire). Dans les faits, nameCont> nameSU serait plus simple.

cdeneux commented 5 years ago

Voici ma vision avec la notion de model. Dans Topologies, il manque le niveau bus.

page-hierarchie

digraph G {

    style=filled;
    color=lightgrey;
    node [style=filled,color=white];
    a0 [label="Accueil / Sélection des espaces de travail"]
    a1 [label="Espace de travail"]
    a2 [label="Vue Topology"]
    a25 [label="Bus importé"]
    a3 [label="Conteneur"]
    a15 [label="Registry node"]
    a0 -> a1;
    a1 -> a2;
    a2 -> a25;
    a25 -> a3;
    a25 -> a15;

    a5 [label="Composants"]
    a55 [label="<Composant> ?"]
    a6 [label="Service Units"]
    a66 [label="<su> ?"]
    a7 [label="Service Assemblies"]
    a77 [label="<sa> ?"]
    a8 [label="Shared Libraries"]
    a88 [label="<sl> ?"]
    a10 [label="admin"]
    a3 -> a10 [style=dashed];
    a3 -> a5; a5 -> a55 [style=dashed];
    a3 -> a6; a6 -> a66 [style=dashed];
    a3 -> a7; a7 -> a77 [style=dashed];
    a3 -> a8; a8 -> a88 [style=dashed];

    ab25 [label="Based-model bus"]
    ab3 [label="Conteneur"]
    ab15 [label="Registry node"]
    a2 -> ab25;
    ab25 -> ab3;
    ab25 -> ab15;

    ab5 [label="Composants"]
    ab55 [label="<Composant> ?"]
    ab6 [label="Service Units"]
    ab66 [label="<su> ?"]
    ab7 [label="Service Assemblies"]
    ab77 [label="<sa> ?"]
    ab8 [label="Shared Libraries"]
    ab88 [label="<sl> ?"]
    ab10 [label="admin"]
    ab3 -> ab10 [style=dashed];
    ab3 -> ab5; ab5 -> ab55 [style=dashed];
    ab3 -> ab6; ab6 -> ab66 [style=dashed];
    ab3 -> ab7; ab7 -> ab77 [style=dashed];
    ab3 -> ab8; ab8 -> ab88 [style=dashed];

    a9 [label="Vue Services"]
    a1 -> a9;
    a11 [label="Vue API"]
    a1 -> a11;

    vuemodel [label="Vue Model"]
    a1 -> vuemodel
    modeltopology [label="Model de topology"]
    modelservices [label="Model de services"]
    modelbus [label="Model de bus"]
    vuemodel -> modeltopology
    vuemodel -> modelservices
    vuemodel -> modelbus
    ab25 -> modelbus [style=dashed, label="est une instance de"];
}
vincent-zurczak commented 5 years ago

Cela ferait une hiérarchie à 7 niveaux. Cela fait beaucoup. En IHM, il faut se souvenir que l'on peut mémoriser 6-7 items (mémoire à court terme).

Un arbre des tâches n'est pas un méta-modèle. :grey_exclamation:

psouquet commented 5 years ago

@cdeneux c'est quoi Based-model bus et Vue model ? Un model généré depuis un bus et un model entièrement logique ?

Aussi, vous voulez dire quoi avec <xxx> ? que c'est un artefact ? une ressource ?

cdeneux commented 5 years ago

Based-model bus est un bus instancié depuis un model. A distinguer d'un bus simplement importé, et donc lié à un model. La modification d'un Based-model bus ne peut se faire qu'au travers d'une modification de son model au contraire du bus importé sur lequel on peut (un)deployer comme on veut. Vue model est la vue qui permettra la création et l'édition des différents modèles.

psouquet commented 5 years ago

Dans ce cas je pense qu'on peut simplifier comme ça :

Capture d’écran de 2019-03-25 11-30-01

Je trouve que ca n'a pas trop de sens que la registry soit "sous" le bus, c'est au même niveau ou "au dessus" selon moi.

Je pense que les vues des bus importés et des bus basés sur un modèle seront assez différentes, mais que les vues des conteneurs/artefacts liés seront similaires, autant les fusionner. De plus, Bertrand veut que l'on puisse ajouter des conteneurs/artefacts logiques (modèles) depuis la vue topologie, un peu comme un patch. On n'aura probablement pas de bus entièrement physique. Je crée une issue pour ca sinon ca fera trop ici. (edit: issue #14 )

digraph G {

    style=filled;
    color=lightgrey;
    node [style=filled,color=white];
    a0 [label="Accueil / Sélection des espaces de travail"]
    a1 [label="Espace de travail"]
    a2 [label="Vue Topology"]
    a25 [label="Imported bus"]
    a22 [label="Registry node"]
    a22 -> a25 [style=dashed label="registers"];
    a22 -> ab25 [style=dashed label="registers"];
    a0 -> a1;
    a1 -> a2;
    a2 -> a25;
    a2 -> a22;

    a3 [label="Conteneur"]
    a25 -> a3;
    a5 [label="Composants"]
    a6 [label="Service Units"]
    a7 [label="Service Assemblies"]
    a8 [label="Shared Libraries"]
    a3 -> a5;
    a3 -> a6; 
    a3 -> a7; 
    a3 -> a8; 

    ab25 [label="Model-based bus"]
    a2 -> ab25;
    ab25 -> a3;

    a9 [label="Vue Services"]
    a1 -> a9;
    a11 [label="Vue API"]
    a1 -> a11;

    vuemodel [label="Vue Model"]
    a1 -> vuemodel
    modeltopology [label="Model de topology"]
    modelservices [label="Model de services"]
    modelbus [label="Model de bus"]
    vuemodel -> modeltopology
    vuemodel -> modelservices
    vuemodel -> modelbus
    ab25 -> modelbus [style=dashed, label="instance of"];
}
cdeneux commented 5 years ago

Petite correction, c'est une registry (et non un registry node) qui peut-être utilisée par plusieurs bus. Non, les vues bus importés et bus basés sur un modèle devraient être identique, à part peut être l'overview du bus. Par contre, les actions possibles seront différentes.

psouquet commented 5 years ago

Euh, pour moi les vues bus importés et bus basés sur un modèle sont des overviews (quand tu clique sur un bus dans l'arbre en gros). Je les ai laissés séparés pour conserver le lien d'instanciation vers le modèle de bus. Les actions sont différentes sur tous les artefacts selon si ils sont sur un bus importé ou basé sur un modèle non ? (pas possible de deploy/undeploy sur un bus de modèle)

cdeneux commented 5 years ago

Oui, mais par contre on a le même arbre pour les deux types de bus

psouquet commented 5 years ago

Il y a quelque chose que je ne comprend pas en fait avec ces diagrammes. Je ne comprend pas ce qu'ils représentent vraiment. Est-ce que c'est vraiment la hiérarchie (dans le sens route, cheminement) des pages que l'on veut ou juste la représentation au sens Petals de ces pages (ie: ce que l'on voit dans le fil d'Ariane).
A l'heure actuelle la hiérarchie (cheminement) est comme cela: graphviz Quand on est sur la "vue topologie" (ie: l'arbre est affiché, il n'y a pas de vue à proprement parler) on peut accéder à tout artefact du Bus directement. Je pense que l'on veut conserver cela, ce serait rébarbatif de devoir passer par tous les parents pour voir les détails d'une SU... Cependant, le but du fil d'Ariane est d'aider à la navigation, donc il faut y représenter hiérarchiquement les elements parents au sens Petals. Non ?

Graphe ``` digraph G { style=filled; color=lightgrey; node [style=filled,color=white]; a0 [label="Accueil / Sélection des espaces de travail"] a3 [label="Administration"] a0 -> a3 [style=dashed label="admin"]; a5 [label="Preferences"] a0 -> a5; a1 [label="Espace de travail"] a2 [label="Vue Topology"] a25 [label="Bus"] a0 -> a1; a1 -> a2; a2 -> a25; a23 [label="Conteneur"] a2 -> a23; a29 [label="Composants"] a26 [label="Service Units"] a27 [label="Service Assemblies"] a28 [label="Shared Libraries"] a2 -> a29; a2 -> a26; a2 -> a27; a2 -> a28; a9 [label="Vue Services"] a1 -> a9; a91 [label="Service"] a92 [label="Interface"] a93[label="Endpoint"] a9 -> a91; a9 -> a92; a9 -> a93; } ```
vincent-zurczak commented 5 years ago

OK avec la dernière proposition. La vue "topologie" est l'arborescence de tout ce qui compose la topologie, ce qui devrait inclure les noeuds de registry de service.

L'arbre est plus lisible en l'état, mais on peut s'interroger sur le fil d'Ariane qui en découle. Le fil d'Ariane ne doit pas représenter une vue logique de Petals, mais le chemin par lequel l'utilisateur est arrivé sur la page actuelle. C'est de l'IHM. Cependant... Si la vue topologie est arborescente, rien n'interdit que le lien (URL) et le fil d'Ariane incorporent des données arborescentes. En tout cas, le point de vue se défend. Ainsi, si je clique dans l'arbre sur "Container 1 > SU 1", cela peut m'emmener vers "container-1/su-1" et afficher le fil "Container 1 > SU 1".

bescudie commented 5 years ago

Une topologie = 1 Bus, mais dans la vue Topologie d'un workspace il y a 1..n Bus

bescudie commented 5 years ago

La question à trancher est de savoir si la Registry est rattaché à un SEUL bus. Techniquement le(s) même(s) serveur(s) de registry peu(ven)t servir à plusieur Bus (?). Est-ce que cela à un sens de partager une Registry entre plusieurs Bus ?

psouquet commented 5 years ago

Mon graphe n'est pas une proposition, c'est la hiérarchie actuelle des pages (version existante de cockpit).

Et je pense, au contraire, que le fil d'Ariane ne doit pas refléter le chemin pris pas l'utilisateur mais la position "physique" de l'artefact dans la topologie. Si l'utilisateur clique sur une SU, peu importe d'ou il vient il verra dans le fil: "Workspace1 -> Topologie > Bus1 > Container1 > Composant1 > SU1". Avec l'arbre, tout element est accessible à tout moment; ce serait vraiment confus d'afficher dans le fil le dernier parent uniquement si il a été visualisé juste avant.

cdeneux commented 5 years ago

Une instance de registry n'a de sens que pour un bus. Toutes les instances sont isolées les unes des autres. Une registry (ou un cluster Hazelcast) peut héberger plusieurs instances de registry, donc être utilisé par plusieurs bus.

vincent-zurczak commented 5 years ago

Et je pense, au contraire, que le fil d'Ariane ne doit pas refléter le chemin pris pas l'utilisateur mais la position "physique" de l'artefact dans la topologie.

Le fil d'Ariane est une notion d'IHM. On trouve aussi la notion de plan d'un site en général, même si ce n'est pas obligatoire.

Une topologie = 1 Bus, mais dans la vue Topologie d'un workspace il y a 1..n Bus

Vous vous rendez compte que les formations Petals mentionnent toutes une topologie comme un "bus" ? Ce sont des conteneurs qui sont mis en relation les uns avec les autres et entre lesquels peuvent circuler des messages... Attention aux termes. Le but in fine, c'est quand même que Petals gagne des utilisateurs et des clients, il faut donc simplifier...

Ce que je propose :

Sans me retaper le graphe...

Si je décline la notion de contexte...

Quel que soit le contexte choisi, un clic dans l'arborescence mène à une URL / fil d'Ariane identique (Topologie > Conteneur > Artefact). Le contexte n'apparaît pas dans l'URL ou le fil d'Ariane. Selon le type d'utilisateur, en revanche, un contexte aura été préféré plutôt qu'un autre.

Quant à un noeud de registry...

psouquet commented 5 years ago

Et je pense, au contraire, que le fil d'Ariane ne doit pas refléter le chemin pris pas l'utilisateur mais la position "physique" de l'artefact dans la topologie.

Le fil d'Ariane est une notion d'IHM. On trouve aussi la notion de plan d'un site en général, même si ce n'est pas obligatoire.

Dans ce cas là soit on ne met pas de fil d'Ariane soit on l’appelle autrement. Je ne vois pas l’intérêt de cette feature si on ne positionne pas l'artefact sur son bus/conteneur/(composant). Sinon c'est exactement comme l’existant autant ne rien toucher et enlever nos changements.

Une topologie = 1 Bus, mais dans la vue Topologie d'un workspace il y a 1..n Bus

Vous vous rendez compte que les formations Petals mentionnent toutes une topologie comme un "bus" ? Ce sont des conteneurs qui sont mis en relation les uns avec les autres et entre lesquels peuvent circuler des messages... Attention aux termes.

Je pense qu'il faut trouver un autre nom à la "Vue topologies" alors. Ca fait un moment qu'on en parle mais on n'a pas trouvé de terme plus précis.

Et sinon j'ai du mal à visualiser ce que tu veux dire par item transverse. C'est une sorte d'item logique qui regroupe toute les topologies du workspace ?

vincent-zurczak commented 5 years ago

Cette notion que j'appelle transverse est ce que j'avais évoqué il y a quelques mois déjà. La vue arborescente qui contient tous les bus n'a d'intérêt que pour une vue SI. Mais elle prête à confusion pour un exploitant, qui travaille sur un bus.

Historiquement, un bus = une topologie = un ensemble de conteneurs Petals qui peuvent échanger des messages les uns avec les autres (via le transporteur). Cela exclut donc les inter-connexions entre des bus au travers du BC gateway. Depuis Petals 5, la notion de bus / topologie s'est enrichie des noeuds de registry.

Du point de vue d'un exploitant, il n'y a pas d'ambiguïté. C'est historique : 1 bus = 1 topologie. La nouveauté que Cockpit a introduite est cette vue multi-bus, multi-topologies, transverse. Et comme je le disais, elle n'a d'utilité que pour certains utilisateurs, à mon avis.

C'est la raison pour laquelle je propose que sur l'accueil d'un espace de travail, on puisse décider de travailler dans un contexte mono-topologie, ou dans un contexte multi-topologies. Quoique l'on choisisse, les IHM vont être quasi-identifiques, les sous-arbres des tâches sont les mêmes, l'expérience utilisateur très proche... mais un utilisateur passera par l'un ou l'autre et cela correspondra à ses objectifs.