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

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

Lunar lunar at anargeek.net
Ven 8 Déc 13:08:35 CET 2006


Le vendredi 08 décembre à 10:14 +0100, Dominique Rousseau écrivait:
> Le Thu, Dec 07, 2006 at 08:02:41PM +0100, Nil [nicolist at limare.net] a écrit:
> [... Live / Batch / Convergence ...]
> 
> L'aspect "convergence", je le trouve assez sympathique.
> 
> Ca permet, pour l'utilisation courante de l'utilisateur non technique
> d'avoir une souplesse similaire au "live", si un signal est envoyé pour
> dire "tiens, il y a des changements à effectuer, là, maintenant,
> j'attends".

Mh.. il peut aussi attendre longtemps, voir très longtemps, si l'état du
système est trop différent du modèle. Voir encore plus longtemps si ça
converge pas...

> Mais ça permet aussi, sans "violer" le système d'effectuer des actions
> en batch, si nécessaire. Par exemple, sur des opérations de "ménage" de
> X comptes, on ajoute dans une sorte de "liste de taches" ce qu'il va y
> avoir à supprimer, ce qui permet de vérifier autant de fois que
> nécessaire qu'on a pas détruit un truc qu'il aurait pas fallu. Et on
> valide le tout en une fois, à exécuter en asynchrone.
> 
> Dans une architecture distribuée, ça peut aussi servir à synchroniser un
> nouveau noeud qui vient d'être installé vers l'état qu'il devrait avoir,
> avant d'être integré aux serveurs "de prod".

Yep. J'y ai encore un peu réfléchi cette nuit, et ce principe
d'architecture permet de faire assez facilement un truc qui intéresse
lautre.net : dans une architecture avec plein de serveurs, ça permet de
prendre en compte une opération du migration d'un serveur à un autre.

Pour faire que ça fonctionne bien, je pense que c'est un peu compliqué,
mais ça devrait donner les gardes-fous nécessaire pour que le reste de
cette histoire de convergence se passe bien.

L'aspect compliqué, c'est qu'on a envie de pouvoir faire la migration en
changeant un seul attribut du modèle. Genre de mettre un 2, là où se
trouvait un 1. L'aspect « tricky », c'est l'éventuel migration des
données.

S'il n'y en a pas, c'est simple : le serveur 1 fait converger le système
vers le modèle qui le concerne, et donc supprime ce qu'il faut. Le
serveur 2 fait lui aussi converger le système vers le modèle qui le
concerne, et crée donc la configuration nécessaire.

S'il y a migration des données, ça devient compliqué (mais
intéressant) : l'un des deux serveurs doit être responsable de la
migration. Si c'est le serveur sur lequel se trouvait les données, il
suffit que l'opération de convergence soit la migration des données,
puis suppression de la configuration. L'autre serveur attendra que les
données existent avant de pouvoir finir de converger, et donc de créer
la configuration.

Pour que ce dernier cas fonctionne, j'ai l'impression qu'il faut
clairement que dans le modèle, on puisse distinguer plein d'états de
l'object : crée/existant/effacé/détruit... Ce que pose du coup un
nouveau problème : il faut un canal de communication « retour » où le
daemon informe le modèle qu'il vient de créer l'objet, par exemple.

Je pense que c'est essentiel d'avoir ça, ou quelque chose d'approchant
pour avoir un feedback visuel vis-à-vis des users dans tous les cas...

Bref, je continue à y réfléchir, bande de méchants. :P

À peluche,
-- 
Lunar                                               http://anargeek.net/
                ·-|-·  無政府ハッカー  ·-|-·
                                                     weather: light rain
Dijon                                                   temp: 11.0 C
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 189 octets
Desc: Digital signature
URL: <http://lists.alternc.org/arch/dev/attachments/20061208/8fcb5539/attachment.pgp>


Plus d'informations sur la liste de diffusion Dev