[AlternC-dev] alternc2.0 : architecture ??

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

Nahuel ANGELINETTI nahuel at altnetvision.info
Jeu 7 Déc 20:15:27 CET 2006


Le problème majeur reste les remontés d'erreur, car cela reste un
système de lots.
Donc soit on fait suffisement de tests pour vérifier qu'à la création
tout va bien, soit on fait du live et ça ne correspond pas à ce
modèle ,et de toutes façons demandra de faire les checks quand meme.

Le système de convergence peut etre pas mal, mais prend le controle sur
tout le système et va pas arreter d'hurler si il y a la moindre
modification faite à la main.

Sinon il faut que le contenu du modèle soit EXACTEMENT le même que
celui du système pour pouvoir faire des checks par les interfaces
d'administration.

Qu'en pensez vous ?

Le Thu, 07 Dec 2006 20:02:41 +0100,
Nil <nicolist at limare.net> a écrit :

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Extrait plus ou moins remis en forme de discussion sur irc, question
> d'architecture au-dela ds details de langage (...).
> C'est pas de moi, hein :)
> 
> Si faire un daemon, c'est juste parce qu'il faut réinventer "crond",
> quel en est l'intérêt. Y a un moment, faut poser des contraintes
> fortes, typiquement, est-ce que le système fonctionnera en "batch" ou
> en "live" ? Mélanger les deux, ça marche jamais bien.
> 
> Actuellement, AlternC fait un mix des deux, du "batch" pour les
> domaines, et du "live" pour les autres fonctionnalites.
> 
> "Live", c'est : les actions sont effectués immédiatement. Quand on
> fait du "live", si ça foire, on le sait tout de suite donc on n'a pas
> d'information erronnées qui trainent.
> 
> "Batch", c'est : traiter un lot de commandes qui est stocke quelque
> part en attente du cycle suivant. Quand on fait du "batch" il faut
> gérer la remontée des erreurs et c'est souvent délicat, vu que c'est
> là où on oublie toujours un bout de code
> 
> Le "batch" pourrait sembler plus sécure, et réduire les risques
> d'injections de codes et autres... Mais un bout de code qui communique
> avec un autre avec une interface bien définie, et des privilèges
> different, ne pose pas plus de problèmes de sécu.
> 
> Après, y a encore un autre paradigme, celui de la "convergence".
> 
> On a un modèle qui représente ce que devrait être l'état quelque part,
> et on a un programme dont le boulot c'est de faire "converger" l'état
> actuel vers celui du modèle. Ca n'est pas forcément si éloigné du
> traitement par lot, mais avec une différence fondamentale : la notion
> de « requêtes » disparaît parce que tu le programme qui s'occupe de
> faire converger le système les génère « à la volée ».
> 
> Pour la remonté d'erreurs, on s'assure que le modèle soit _correct_,
> et s'il l'est pas, on le détecte, et on hurle qu'on peut pas
> converger. Peut-être plus complique, mais ca peut être une solution
> très fiable.. parce que ça permet de retrouver un état cohérent en
> cas de problèmes (et peut-être une des solutions les plus simples
> pour faire du multi-serveur)
> 
> Un peu de details: le truc qui fait la convergence, c'est un daemon.
> Au chargement, il analyse l'état du système. Il pose ensuite des
> accroches aux endroits du système dont il a besoin d'être informé
> quand il y a un changement (parce qu'on ne peut pas faire confiance
> aux roots). Il a donc l'état du système en mémoire.
> Ensuite, il se connecte au modèle (typiquement, la base de données),
> en vérifie la cohérence,  et calcule les différences existent entre le
> modèle et l'état actuel du système. Il va alors s'efforcer de réduire
> ces différences (en créant par exemple une boite mail qui est dans la
> table des boites mails, et qui existent pas dans /var/lib/mail). Une
> fois que l'état a convergé, il s'endort, et se réveille lorsque le
> système, ou le modèle change.
> L'interface avec le monde extérieur est réduite au minimum : un signal
> quand le modèle change, et un acces  au modèle (+ inotify, pour avoir
> un filet de sécurité pour les mouvements qui passent pas par lui)
> 
> Contrainte: le daemon doit avoir l'exclusivité des changements du
> systeme qui entrent dans son champ de compétence; on ne peut pas ou ne
> doit pas creer sur ce système une boite mail ou un domaine ou changer
> la configuration de ceux-ci sans passer par alternd (le daemon), soit
> en passant par une ui web, soit par le shell alternsh. AlternC doit
> etre seul maître a bord, dans son contexte. Le (v)server ne sert qu'a
> alternc. On ne doit pas faire en-dehors d'AlternC ce que AlternC peut
> faire; c'est pas forcement mal, mais ca n'est pas le fonctionnement
> actuel.
> 
> La question du design ou de l'implémentation des interfaces humaines
> (en ligne de commande ou par le web) est distincte, et on peut
> envisager autant d'interfaces que de goûts et couleurs, du web
> php/java/ruby/autres/..., de la ligne de commande classique ou en
> curses, un client-server SOAP/XMLRPC/..., selon les usages. Les
> interfaces ne communiquent pas avec le daemon, elles modifient le
> modèle (la base de données), et le daemon va agir sur le système si
> le nouveau modèle est valable. Sinon, le daemon refuse ces
> modifications, et le hurle très fort (comment?). Dan ce cas, le
> système reste dans l'état stable qu'il avait avant les propositions
> de modifs, et le modèle reste sur sa proposition, non appliquée.
> 
> C'est a ce moment que des mails **ALERTE** sont envoyés aux admins et
> que la sirène USB se déclenche...
> 
> - --
> Nil
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> 
> iD8DBQFFeGVQvviFAPpCP08RAi3dAJ9AnHdnqwfGfGYPPq3Bspa2/52zHACfdUIe
> 4OHQ+gzs7qL//JPowh/6vdY=
> =LfQj
> -----END PGP SIGNATURE-----
> _______________________________________________
> Dev mailing list
> Dev at alternc.org
> http://alternc.org/cgi-bin/mailman/listinfo/dev


-- 
Nahuel ANGELINETTI
Association ~altNetVision
Jabber/XMPP : nahuel at ahtna.org



Plus d'informations sur la liste de diffusion Dev