[AlternC-dev] Koumbit, AlternC et Hostmaster

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

The Anarcat anarcat at anarcat.ath.cx
Lun 29 Sep 16:36:33 CEST 2008


On Mon, Sep 29, 2008 at 03:49:05PM +0200, Nahuel ANGELINETTI wrote:
> The Anarcat a écrit :
> > On Fri, Sep 26, 2008 at 07:29:13PM +0200, Nahuel ANGELINETTI wrote:
> >   
> >> Le Fri, 26 Sep 2008 10:01:16 -0400,
> >> The Anarcat <anarcat at anarcat.ath.cx> a écrit :
> >>
> >>     
> >>>> The Anarcat a écrit :
> >>>>         
> >>> [...]
> >> Rah, j'ai un sacré problème avec ces "cronjob", c'est pas instantané...
> >> et qu'en est il d'autres services qu'apache qui ont besoin d'une
> >> création de répertoire(les mails) ?
> >>     
> >
> > Ils sont pas créés sur le champ, tout simplement.
> >   
> Il me semblait que cette méthode était considéré comme "ultra-chiante"
> pour les utilisateurs et que l'idée d'un daemon était plus convenable,
> qui peut entre autre retourner un code d'erreur en live.

Comme christian a déjà mentionné, il n'y a pas besoin de créer les
mailboxes explicitement. D'ailleurs j'ai jamais eu de problème avec ça
en particulier dans AlternC.

Ceci dit, hostmaster prévoit déjà un moyen de retourner de l'information
du cronjob.

> >>>> Comment gérer les nodes?
> >>>>         
> >>> J'imagine que tu parles ici des serveurs: de mon point de vue, c'est
> >>> ici la tâche de Puppet de configurer les nodes avec un serveur web, un
> >>> serveur MySQL, etc. Hostmaster est cependant conçu pour être
> >>> multi-serveurs et donc pour configurer plusieurs machines à distance,
> >>> avec SSH.
> >>>       
> >> Et pour répartir les configurations, etc...? Puppet avait des problèmes
> >> de tenue de charge selon mes souvenirs.
> >
> > Puppet se comporte très bien avec beaucoup de serveurs. C'est quand on
> > parle de beaucoup de configuration par serveur que ça commence à moins
> > bien tenir la route. Donc mettre tous les usagers dans puppet, ça scale
> > pas.
> >   
> 
> Tout passerait par de la conf de puppet alors?

Pas nécessairement. AlternD serait indépendant de Puppet, mais Koumbit
utiliserait puppet pour configurer AlternD, donc des recettes seraient
disponibles pour ça. Nous faisons déjà ce travail pour AlternC,
d'ailleurs.

> >>> Prenons l'exemple d'un node Web à ajouter. Puppet (ou un sysadmin) va
> >>> installer Apache puis la configuration minimal nécessaire à hostmaster
> >>> pour traiter les tâches le concernant. Dès lors, le cron job sur cette
> >>> machine va effectuer les tâches normalement.
> >>>       
> >> Personnellement j'aurais plus vu le bouzin comme un daemon qui tourne
> >> sur chaque node, et qui attend les tâches à jouer de la part d'un
> >> maitre en fonction des modules activés.
> >>     
> >
> > C'est comme ça que hostmaster1 était écrit et c'était un peu bourrin
> > parce que personne comprenait comment il marchait.. En utilisant du PHP
> > en backend aussi, ça simplifie les choses et ça n'empêche pas de
> > ré-écrire le backend en daemon si on veut mieux scaler à l'avenir.
> 
> C'est une question de documentation si personne ne comprend, pas une
> question de fonctionnement. Dans le principe dans ressemblerait à
> quelquechose comme puppet, dans le fonctionnement ce serait quelquechose
> de plus adapté à un système modulable/node dont un maître récupère
> toutes les méthodes et les autorise ou pas à son utilisateur.

Je comprends pas trop ici..

> >>>> Pourquoi Drupal?
> >>>>         
> >>> Drupal est un choix assez pragmatique: c'est la plateforme de
> >>> développement de choix de Koumbit depuis ses débuts. C'est un logiciel
> >>> qui s'est prouvé très extensible et facile à programmer, même pour des
> >>> programmeurs n'ayant jamais utilisé ou programmé Drupal.
> >>>
> >>> De plus, Hostmaster existe déjà et fait *beaucoup* de ce que nous
> >>> avons besoin. Je compte fort sur les modules de gestions de mailing
> >>> list, Bind et gestionnaire de fichiers déjà existants dans Drupal
> >>> pour faciliter le développement futur d'AlternD également.
> >>>
> >>> Donc en bref, pourquoi Drupal? Pour ne pas réinventer la roue.
> >>>       
> >> Ça n'est pas un peu lourd pour les besoins?
> >
> > Selon moi, non.
> 
> Est il question de séparer les dev "core" et "gui"? Pour pouvoir
> intégrer différents UI?

Non.

> >>>> J'en ai d'autres, mais déjà répondre à celles là ce serait pas mal.
> >>>>         
> >>> Voilà, j'espère que ça répond à tes questions. :)
> >>>       
> >> L'idée de nodes daemonisés ça t'intéresse pas?
> >>     
> >
> > C'est intéressant, mais trop compliqué.
> Mais très intéressant à développer, et évolutif :)

Pourquoi pas. T'es en charge, bravo. ;)

> >>> Non, pas pour l'instant. C'est un système de "provisionning",
> >>> seulement de Drupal pour l'instant.
> >>>
> >>> C'est en version 0.1-alpha, à ce stade-ci, d'ailleurs, donc ce n'est
> >>> pas grand chose. Un paquet d'idées de concepts et de code.
> >>>
> >>> Mais je (et d'autres développeurs de aegir) veulent aussi en faire une
> >>> plateforme d'hébergement mutualisée générique. D'autres sont également
> >>> intéressés au provisionning de vservers.
> >>>       
> >> En fait, l'idée est bien, mais pour moi drupal ne devrait pas être
> >> celui qui touche au système. J'irais plutôt dans le sens ou le "drupal"
> >> communique avec un daemon, qui pourrait d'ailleurs avoir pleins de GUI
> >> disponibles.
> >>     
> >
> > C'est une vieille idée, mais je ne vois pas ça arriver avant un bon bout
> > de temps, c'est trop compliqué: il faut une trop grande cohésion entre
> > le GUI et le backend pour complètement les séparer, à mon avis.
> >
> >   
> Si l'API du backend est bien définie je ne vois pas en quoi c'est trop
> compliqué, et ça permet de bien séparer les rôles de chaque partie du code.

C'est compliqué parce que ça fait beaucoup de code pour pas grand chose.

A.

-- 
C'est trop facile quand les guerres sont finies
D'aller gueuler que c'était la dernière
Amis bourgeois vous me faites envie
Ne voyez vous pas donc point vos cimetières?
                        - Jaques Brel
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 197 octets
Desc: Digital signature
URL: <http://lists.alternc.org/arch/dev/attachments/20080929/6c5cd0da/attachment.pgp>


Plus d'informations sur la liste de diffusion Dev