Produits Entr'ouvert » Hobo

Un patch qui aurait juste désactivé le provisionning sur migrate_schemas aurait paru plus sûr (ok le code est mieux après le patch car l'action est explicite, par contre le patch en lui-même est 0 explicite et s'en remet à l'imagination du lecteur pour comprendre quelles commandes sont impactées).

À part ça j'aimerais bien un cours de rattrapage sur le provisionning, il ne se fait plus pendant la migration et du coup il se fait quand ?

Valentin Deniaud a écrit :

Un patch qui aurait juste désactivé le provisionning sur migrate_schemas aurait paru plus sûr (ok le code est mieux après le patch car l'action est explicite, par contre le patch en lui-même est 0 explicite et s'en remet à l'imagination du lecteur pour comprendre quelles commandes sont impactées).

Au contraire tu as la liste explicite des commandes impactées, je ne comprends pas cette remarque.

À part ça j'aimerais bien un cours de rattrapage sur le provisionning, il ne se fait plus pendant la migration et du coup il se fait quand ?

Jamais. Si jamais il y avait besoin de provisionning dans une migration, il faut le prévoir explicitement, idem dans un shell. Pour runscript le provisionning est maintenu.

Benjamin Dauvergne a écrit :

Au contraire tu as la liste explicite des commandes impactées, je ne comprends pas cette remarque.

J'ai la liste des commandes qui ne sont pas impactées par le patch , c'est à dire celles dont le fonctionnement va rester le même. Je n'ai pas la liste des commandes dont le comportement va être modifié.

Valentin Deniaud a écrit :

Benjamin Dauvergne a écrit :

Au contraire tu as la liste explicite des commandes impactées, je ne comprends pas cette remarque.

J'ai la liste des commandes qui ne sont pas impactées par le patch , c'est à dire celles dont le fonctionnement va rester le même. Je n'ai pas la liste des commandes dont le comportement va être modifié.

Ok c'est bizarre mais tu considères qu'avoir le provisionning est le fonctionnement normal des commandes de Django mais ce n'est pas le cas. Là tu as la liste explicite des commandes pour lesquelles du provisionning sera fait, comme le problème c'est d'avoir du provisionning et non pas de ne pas en avoir ça me parait ok. Le provisionning est en premier lieu fait pour avoir lieu au cours d'une requête pour des modifications faites en front ou back office. L'introduction du provisionning au niveau des commandes a été fait principalement pour la commande de synchro LDAP et les scripts, c'est maintenu.

Benjamin Dauvergne a écrit :

Ok c'est bizarre mais tu considères qu'avoir le provisionning est le fonctionnement normal des commandes de Django

... Je dis juste que le patch ne se limite pas à corriger le problème du ticket, je ne dis même pas que c'est mal je dis que ça m'aurait « paru plus sûr ».

Peut-être que ça ne m'aurait pas donné cette impression s'il y avait eu des tests.

Bref revenons-en au fond,

il ne se fait plus pendant la migration et du coup il se fait quand ?

Jamais.

J'ai écrit une migration comme celle du ticket lié, zappé qu'il fallait prévoir le provisionning à l'avance, les rôles sont créés. Quelle sera la marche à suivre pour remettre les choses d'équerre ?

Valentin Deniaud a écrit :

J'ai écrit une migration comme celle du ticket lié, zappé qu'il fallait prévoir le provisionning à l'avance, les rôles sont créés. Quelle sera la marche à suivre pour remettre les choses d'équerre ?

Le provisionning qui a lieu dans les migrations authentic est inutile, ces rôles d'administration ne servent à rien dans les services et ne changent rien dans les worklows. Le seul provisionning utile concerne les rôles utilisés dans des workflows ou des formulaires pour l'envoi des mails de notification et la mise à jour de l'adresse mail elle même (c'est le seul cas où si un provisionning n'a pas lieu on aura un souci), le reste ne sert à rien ou n'a pas d'impact signifiant (genre changer nom/prénom d'un utilisateur pour l'affichage, c'est pas signifiant et ça se corrigera tout seul au prochain login).

Pour l'instant le code de provisionning est trop simple pour faire ces distinctions et se déclenche à la moindre modification du graphe des rôles ou d'un utilisateur. Dans le même ordre d'idée le provisionning vers les briques autre que combo et w.c.s. est inutile. Et sur combo le provisionning de l'appartenance aux rôles ne sert à rien non plus.

On a surtout encore un gros manque de provisionning en pull depuis w.c.s. et combo (une bête synchro) qui rendrait ces discussions encore moins utiles.

Automatic expiration