https://dev-eole.ac-dijon.fr/https://dev-eole.ac-dijon.fr/favicon.ico2014-09-25T06:46:48ZEnsemble Ouvert Libre Évolutifeole-pacemaker - Tâche #8993: Corosynchttps://dev-eole.ac-dijon.fr/issues/8993?journal_id=349492014-09-25T06:46:48ZFabrice Barconnièrefabrice.barconniere@region-academique-bourgogne-franche-comte.fr
<ul><li><strong>Tracker</strong> changé de <i>Anomalie</i> à <i>Bac à idée</i></li><li><strong>Projet</strong> changé de <i>Distribution EOLE</i> à <i>eole-pacemaker</i></li><li><strong>Distribution</strong> changé de <i>EOLE 2.3</i> à <i>EOLE 2.4</i></li></ul><p>Plus d'évolution en 2.3.<br />On trouve des messages d'erreur dans les logs à 6h26 avant que ce phénomène ne survienne. Ça correspond à l'heure de rotation des logs. Dans la configuration logrotate, les ressources sont mises à <strong>unmanage</strong> (la commande est lancée 2 fois). Quand le logrotate d'un noeud se termine, les ressources sont repassées en <strong>manage</strong> alors que l'autre noeud n'a pas terminé, ce qui pourrait rendre le cluster instable.</p>
<p>L'idée serait de faire un scp d'un lock (via l'interface de dialogue) sur le noeud distant puis de le supprimer quand il a terminé.<br />Le premier qui logrotate doit mettre les ressources unmanaged et le dernier qui termine les remet en surveillance.</p> eole-pacemaker - Tâche #8993: Corosynchttps://dev-eole.ac-dijon.fr/issues/8993?journal_id=350312014-09-25T13:03:33ZPhilippe Caseiropcaseiro@cadoles.com
<ul><li><strong>Statut</strong> changé de <i>Nouveau</i> à <i>Résolu</i></li><li><strong>% réalisé</strong> changé de <i>0</i> à <i>100</i></li></ul><p>Appliqué par commit <a class="changeset" title="tmpl/haute_dispo.logrotate: Ajout d'un sleep au logrotate On attend quelques secondes pour que l..." href="https://dev-eole.ac-dijon.fr/projects/eole-pacemaker/repository/revisions/c3d7010393a688bb9e5010a4daa7d25409c92d71">c3d7010393a688bb9e5010a4daa7d25409c92d71</a>.</p> eole-pacemaker - Tâche #8993: Corosynchttps://dev-eole.ac-dijon.fr/issues/8993?journal_id=350662014-09-25T15:07:11ZPhilippe Caseiropcaseiro@cadoles.com
<ul><li><strong>Assigné à</strong> mis à <i>Philippe Caseiro</i></li></ul> eole-pacemaker - Tâche #8993: Corosynchttps://dev-eole.ac-dijon.fr/issues/8993?journal_id=350672014-09-25T15:11:44ZPhilippe Caseiropcaseiro@cadoles.com
<ul><li><strong>Tâche parente</strong> mis à <i>#8830</i></li></ul> eole-pacemaker - Tâche #8993: Corosynchttps://dev-eole.ac-dijon.fr/issues/8993?journal_id=385692014-11-24T11:03:32ZEmmanuel GARETTE
<ul><li><strong>Description</strong> mis à jour (<a title="Voir les différences" href="/journals/38569/diff?detail_id=51496">diff</a>)</li><li><strong>Temps estimé</strong> mis à <i>0.25 h</i></li><li><strong>Restant à faire (heures)</strong> mis à <i>0.25</i></li></ul> eole-pacemaker - Tâche #8993: Corosynchttps://dev-eole.ac-dijon.fr/issues/8993?journal_id=386662014-11-25T15:44:15ZFabrice Barconnièrefabrice.barconniere@region-academique-bourgogne-franche-comte.fr
<ul><li><strong>Statut</strong> changé de <i>Résolu</i> à <i>Fermé</i></li><li><strong>Restant à faire (heures)</strong> changé de <i>0.25</i> à <i>0.0</i></li></ul><p>Après un logrotate, le cluster reste stable.</p> eole-pacemaker - Tâche #8993: Corosynchttps://dev-eole.ac-dijon.fr/issues/8993?journal_id=386752014-11-26T07:18:53ZKarim Ayarikarim.ayari1@ac-lyon.fr
<ul></ul><p>c'est tout de même dommage qu'une petite modification comme celle-ci ne soit pas portée en 2.3!</p>