[AlternC-dev] Gestion de création des ressources

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

Alban Crommer alban at octopuce.fr
Lun 7 Juil 00:53:34 CEST 2014


Ola all, 

Réponse un peu longue, pour discussion en résumé il me semble que sous réserve d'une bonne analyse des contraintes / besoins / PRO-CON c'est un changement architectural intéressant surtout dans le cadre de la réflexion sur l'API. 

Rappel 

On a aujourd'hui une classe m_action by steven & fufroma : elle gère uniquement ce qui touche aux créations de fichiers / dossiers 

    • La classe crée des enregistrement en db des actions à effectuer cf. http://doc.alternc.org/latest/html/classm__action.html 
    • Elle déclenche immédiatement v ia un INOTIFY un worker cf. http://doc.alternc.org/latest/html/inotify__do__actions_8sh_source.html 
    • Celui-ci va prendre en charge le(s) job(s) qu'on lui a donné en tapant dans la db cf. http://doc.alternc.org/latest/html/do__actions_8php_source.html 

Contexte / Problèmes 

Si je fais un petit florilège des choses que m'évoquent ce sujet 

    • On exécute beaucoup d'actions dans alternc. 
    • Certaines actions sont immédiates (mkdir) d'autres différées (create subdomain) 
    • Les informations sur les actions sont cruciales pour l'utilisateur. 
    • Un utilisateur ne retrouve pas l'historique des actions sur son compte 
    • L'utilisateur n'aime pas attendre et encore moins ne pas comprendre ce qui se passe 
    • Les actions d'un user ne sont pas enregistrées pour tous les "services" ie web, dns, mail, etc 
    • Certains scripts ciblent tous les comptes à chaque passage et deviennent non performants / gourmands en ressources cf. le mail sur fixperms.sh de _fil_ 
    • On a pas de données sur le nombre d'actions et leur durée pour optimiser 
    • Avec l'API HTML qu'on conçoit pour fonctionner sur des clients asynchrones, il faut penser à un canal de communication séparé pour communiquer sur les actions qui seront exécutées par cette API 

Solution proposée par fser 

Faire que le maximum d'opérations passe par des actions mises dans une file ? 

[client ] -> [appel API ] -> [Ajout à la file] -> [Traitement par ordonnanceur] -> [Exécution : OK, erreur, rejet] 
^ | 
|___ ______________________________< feedback asynchrone <________________________ _ | 

Au vu des remarques évoquées, ça me semble être un système intéressant si on arrive à le généraliser. 

Voici ce qui me semble quelques facteurs pour avancer 

- Exécution aussi rapide que possible des tâches prioritaires (Ex le FTP d'Olivier) : utiliser une file à priorité non-préemptive ? 
- Optimisation multi-threads : faire du muttithread et gérer en option le nombre de workers Ex: QueueMaster(1 thread réservé) / QueuePriority(1 thread réservé) / QueueWorkers( (N threads - 2) threads dispo ) 
- Mettre à disposition des utilisateurs des notifications / alertes et des historiques des opérations : API de l'ordonnanceur 
- Personnalisation par l'adminsys selon ses besoins : surcharge des appels, traitement des erreurs, contrôle des performances etc. : Système de plugins 
- Remplacement autant que possible des scripts cronifiés 
- Mise à disposition de données chiffrées sur le temps de traitement des opérations 
- Gestion de l'attente si on veut être en mode synchrone 
- Capacité à prévoir le temps de traitement 
- Mettre à disposition de l'adminsys des outils pour suivre l'activité de l'ordonnanceur, les erreurs et les performances des actions 

----- Original Message -----

> From: "Olivier HUET" <contact at olivierhuet.fr>
> To: "Liste de Développement de nouvelles fonctionnalités pour
> AlternC" <dev at alternc.org>
> Sent: Saturday, July 5, 2014 2:28:53 PM
> Subject: Re: [AlternC-dev] Gestion de création des ressources

> Bonjour à tous,

> J'avoue que je ne suis plus trop le projet depuis longtemps, mais
> cette idée m'interpelle...

> Personnellement j'ai du mal à voir l'intérêt et, à contrario, en tant
> qu'utilisateur je n'aime pas attendre... si je veux créer un compte
> FTP j'aime que ce soit fait tout de suite et non pas mis dans une
> file pour être fait "plus tard"...
> Je trouve déjà pénible d'attendre lors de la création d'un domaine.
> Donc, d'un point de vue utilisateur, cette évolution serait plus pour
> moi une régression.

> Olivier

> Envoyé depuis un mobile Samsung

> -------- Message d'origine --------
> De : François
> Date :05/07/2014 00:14 (GMT+01:00)
> A : Liste de Développement de nouvelles fonctionnalités pour AlternC
> Objet : [AlternC-dev] Gestion de création des ressources

> Bonsoir à tous,

> alors que j'allais modifier la classe m_ftp pour changer un mkdir en
> $action->create_dir() je me suis rendu compte que cela n'était pas
> trivial :
> actuellement, la classe est synchrone, donc elle fait mkdir et teste
> si le dossier est fait.
> la classe action elle, est asynchrone, elle va juste "notifier" un
> autre "worker" qu'il doit faire des tâches, qui seront, ultimement
> faites.

> J'ai donc pensé au changement (radical) suivant : architecturer la
> création de ressources dans une file.

> On veut ajouter un sous domaine ? On enfile la demande, et on met
> dans le panel "la tâche va être processée".
> Dans un autre coin du panel, on a l'ensemble des tâches réalisées,
> ainsi que le résultat (en gros echec / succès).

> Du coup, plus de probleme de mkdir: on enfile "je veux faire un
> compte FTP".
> Le truc qui fait le compte ftp peut, lui, être synchrone car c'est un
> process indépendant, et dédié.
> Et au bout d'un moment, le panel peut afficher le status de la tâche
> : "compte ftp <<machin>> créé avec succes", ou afficher l'erreur.

> C'est chouette non?
> Vous voyez des cas pour lesquels ça marche pas?

> Bonus : plus de gestion de log dans le panel, à priori il juste
> marche.
> Bonus 2 : si on veut faire un ptit job en autre chose que php, on
> peut.

> --
> François

> _______________________________________________
> Dev mailing list
> Dev at alternc.org
> http://lists.alternc.org/listinfo/dev

> _______________________________________________
> Dev mailing list
> Dev at alternc.org
> http://lists.alternc.org/listinfo/dev
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.alternc.org/arch/dev/attachments/20140707/7f243917/attachment.html>


Plus d'informations sur la liste de diffusion Dev