Discussion :

[csperandio]

Bonjour à tous,

Je me suis lancé dans le projet Argus Supervisor Server (ASS) qui est hébergé sur ce site. J'ai écrit un document présentant mon idée d'architecture et je voudrais avoir différents avis

Pour toute personne qui a un peu de temps (et qui voudrait participer au projet), je vous invite à aller sur http://projets.developpez.com/news/show/20

Merci d'avance

[Patriarch24]

Salut.
J'ai lu tes documents. L'idée me semble bonne, et surtout ça m'a l'air intéressant.
J'ai quelques questions :

Cette solution permettra de planifier, d’exécuter, d’arrêter et de surveiller l’exécution.

Argus sera donc capable de gérer l'exécution de scripts shell, d'applications C en ligne de commande, etc. c'est bien ça ?

notification aux utilisateurs de l'avancement de leur traitement par mail

Argus sera aussi capable de donner un avancement de scripts shell, d'applications C en ligne de commande, etc. c'est bien ça ?

Autres questions :
- J'imagine qu'il n'est pas envisageable de réécrire les scripts et programme en ligne de commande, le système doit donc ne pas être intrusif : comment comptes-tu donner un avancement du traitement ? Par heuristiques et/ou statistiques ?
- Pour la même raison, comment comptes-tu arrêter proprement un script/programme lancé en ligne de commande ? Ou cela n'est pas "grave" de l'arrêter brutalement ?
- Y-a-t-il une notion de session ou pas ?

Pour terminer : as-tu déjà fais une recherche sur les outils déjà existants, et si oui, qu'as-tu trouvé ?

[csperandio]

Salut.
J'ai lu tes documents. L'idée me semble bonne, et surtout ça m'a l'air intéressant.
J'ai quelques questions :

Argus sera donc capable de gérer l'exécution de scripts shell, d'applications C en ligne de commande, etc. c'est bien ça ?

C'est bien cela. Argus lancera tout programme qui s'exécute en ligne de commande.

Argus sera aussi capable de donner un avancement de scripts shell, d'applications C en ligne de commande, etc. c'est bien ça ?

Concernant l'avancement, je ne suis pas sûr que cela soit possible
Ma vision est plus de donner le temps de travail du programme (temps effectif et peut être temps d'utilisation processeur). Le problème de l'avancement est que c'est loin d'être uniforme :/

Autres questions :
- J'imagine qu'il n'est pas envisageable de réécrire les scripts et programme en ligne de commande, le système doit donc ne pas être intrusif : comment comptes-tu donner un avancement du traitement ? Par heuristiques et/ou statistiques ?

Je ne pense pas pouvoir donner l'avancement Dans la structure où je suis, il nous arrive de lancer un programme qui fait de la restructuration d'adresses postales. Et il est impossible de savoir à l'avance combien de temps cela prendra (dépend de la taille du fichier, de sa *qualité* en entrée, etc.)

- Pour la même raison, comment comptes-tu arrêter proprement un script/programme lancé en ligne de commande ? Ou cela n'est pas "grave" de l'arrêter brutalement ?

Sous système Unix, il est envisageable de faire l'arrêt en 2 temps: le premier on envoie un signal correspondant au ctrl-C. Le programme recevant ce signal devrait *en théorie* comprendre qu'on lui demande son arrêt et le faire proprement. Si ce signal ne donne pas l'effet escompté, on peut envisager de tuer le processus.

Le produit (maison) qui nous utilisons pour notre projet au boulot fait un kill -9 sur le processus directement.

- Y-a-t-il une notion de session ou pas ?

Euh... non. Tu aurais un cas pratique à me présenter ?

Pour terminer : as-tu déjà fais une recherche sur les outils déjà existants, et si oui, qu'as-tu trouvé ?

En fait, une recherche avait été faite au début du projet sur lequel j'ai bossé au bureau. Lsf et Mosix par exemple ont été trouvés et le choix s'est porté sur un développement interne car lsf coutait très cher et mosix est un système d'exploitation à installer. Le souci est que dans la structure où je suis, nous avons un service d'exploitation formé pour utiliser Red Hat et exclusivement Red Hat. Et il est vrai, qu'installer un OS Linux spécialisé sur des serveurs, cela demande du temps, de la compétence, peux y avoir des problèmes de compatibilité, etc.

[rberthou]

Ton projet semble effectivement intéressant et ayant eu ce type de problématique, je me permets donc de te faire mon retour d'expérience sur ce sujet.

Les points suivants risquent de poser problèmes :
- Que ce passe t'il si l'on souhaite soumettre des travaux via Argus ou en ligne de commande (cron ou autre)
- suspendre un job - cela risque d'etre dangereux pour le SI si cela n'est pas prévus (libération des verrous, ...)
- La console Argus permet elle de visualiser le résultat des travaux (logs, fichiers data, ...)

Je pense qu'il ne faut pas hésiter a etre intrusif sur les scripts (cela permets en plus de les normaliser et d'externaliser certaines fonctions dans des bibliothèques)

[csperandio]

Les points suivants risquent de poser problèmes :
- Que ce passe t'il si l'on souhaite soumettre des travaux via Argus ou en ligne de commande (cron ou autre)

Je suis justement en pleines questions
Le serveur Argus doit-il être autonome avec une interface réseau pour recevoir les requêtes. Dans ce cas, tout programme pouvant envoyer un fichier xml par le réseau serait susceptible d'envoyer des requêtes de traitements au serveur Argus.
Ou bien le serveur devrait-il être un composant intégré dans une application Web (Grails, J2EE, etc.) ? Dans mon organisation, ce serait ce choix le plus adapté (gestion des utilisateurs, sécurité, etc faits au niveau de l'appli web).
Mais, je ne sais pas encore très bien quelle solution choisir

- suspendre un job - cela risque d'etre dangereux pour le SI si cela n'est pas prévus (libération des verrous, ...)

La pause est toujours pour moi un souci. Fonctionnellement, cela est sympathique mais cela pose tellement de problèmes techniques (dont ceux que tu as cités). Je ne pense que je l'intégrerai dans l'immédiat (voire jamais).

- La console Argus permet elle de visualiser le résultat des travaux (logs, fichiers data, ...)

Pour moi, Argus surveille les traitements dont il a la charge. Ces travaux étant de toutes sortes avec des sorties différentes (base de données, fichiers plats, pdf, etc.), je laisse l'utilisateur utiliser ses outils pour voir les résultats.

Je pense qu'il ne faut pas hésiter a etre intrusif sur les scripts (cela permets en plus de les normaliser et d'externaliser certaines fonctions dans des bibliothèques)

Cela dépend du travail d'intégration que les organisations sont prêtes à faire pour mettre en place Argus. Là où je suis actuellement, nous avons quantité de programmes pour réaliser la production mais, cela ne poserait pas de problème de les encapsuler dans des scripts. Mais est-ce le cas pour le plus grand nombre ?

[rberthou]

Je suis justement en pleines questions
Le serveur Argus doit-il être autonome avec une interface réseau pour recevoir les requêtes. Dans ce cas, tout programme pouvant envoyer un fichier xml par le réseau serait susceptible d'envoyer des requêtes de traitements au serveur Argus.
Ou bien le serveur devrait-il être un composant intégré dans une application Web (Grails, J2EE, etc.) ? Dans mon organisation, ce serait ce choix le plus adapté (gestion des utilisateurs, sécurité, etc faits au niveau de l'appli web).
Mais, je ne sais pas encore très bien quelle solution choisir

Personnellement je prefere limiter le serveur web a role de console de supervision car les applications lancees par Argus doivent tourner sans probleme meme si ce serveur d'application est HS.

Pour moi, Argus surveille les traitements dont il a la charge. Ces travaux étant de toutes sortes avec des sorties différentes (base de données, fichiers plats, pdf, etc.), je laisse l'utilisateur utiliser ses outils pour voir les résultats.

Pour la production le suivit des travauux doit etre homogene que celui ci soit traite par Argus ou non. De plus si on suis un traitement on souhaite parfois acceder au logs de celui ci facilement (surtout en cas d'erreur).

Cela dépend du travail d'intégration que les organisations sont prêtes à faire pour mettre en place Argus. Là où je suis actuellement, nous avons quantité de programmes pour réaliser la production mais, cela ne poserait pas de problème de les encapsuler dans des scripts. Mais est-ce le cas pour le plus grand nombre ?

Dans tous les cas la mise en place d'un tel outils est une redefinition de "l'exploitation" donc (personnelement) cela ne me gene pas si des scripts sont à modifier (par contre pas d'intrusion dans les binaires bien sur).

[csperandio]

Personnellement je prefere limiter le serveur web a role de console de supervision car les applications lancees par Argus doivent tourner sans probleme meme si ce serveur d'application est HS.

Pour rappel, ce n'est pas le serveur Argus qui lance les traitements à proprement parler Ce sont les agents installés sur chaque serveur de traitements. Le serveur Argus est une sorte de dispatcher qui sélectionne la meilleure machine pouvant exécuter un traitement.

Pour la production le suivit des travauux doit etre homogene que celui ci soit traite par Argus ou non. De plus si on suis un traitement on souhaite parfois acceder au logs de celui ci facilement (surtout en cas d'erreur).

Quand tu parles des logs, tu parles de ceux du système Argus ?

[rberthou]

Pour rappel, ce n'est pas le serveur Argus qui lance les traitements à proprement parler Ce sont les agents installés sur chaque serveur de traitements. Le serveur Argus est une sorte de dispatcher qui sélectionne la meilleure machine pouvant exécuter un traitement.

Quand tu parles des logs, tu parles de ceux du système Argus ?

Pas uniquement, je pense aux logs de chaqu un des scripts exécutés (al sortie standard et/ou erreur)

[csperandio]

Pas uniquement, je pense aux logs de chaqu un des scripts exécutés (al sortie standard et/ou erreur)

Ok je n'y avais pas pensé. C'est une bonne idée. Je la noterai quand je décrirai l'exécution des traitements.