Le 16 sept. 2009 à 22:51, Karanbir Singh a écrit : > On 09/16/2009 03:33 PM, Miguel Sanchez wrote: >> Hi. Today I have updated my cluster installation with the version >> cman-2.0.115-1 through yum update. When I have started the cman >> service >> , it fails. > > I've added this issue : > http://bugs.centos.org/view.php?id=3842 > > And published openais packages that should address the issue, could > someone with the issue test those and let us know asap. > > Reporting back on the issue tracker > reporting back on the mailing > list > > thanks > > -- > Karanbir Singh : http://www.karan.org/ : 2522219 at icq > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos Sorry, but I wont test that : all my cman servers are part of clusters in production and I will not do any test with part of packages being 5.3 based and other 5.4 based because it means I am doing the QA stuff under in product environments. We are using Centos because it is synchronised with the QA process of the upstream enterprise. With your new policie, we now have several cases : A) Release x.y that is sync with upstream we only drawback for me is that there is 1-3 days of delay between the release of a patch from upstream and the integration into centos. But for most of us this is OK. If not, we can always buy the original product from upstream. B) Release x.(y+1) from upstream, not yet validated under centos When upstream create a dot subversion, there is always a long time (10-90 days) in order for the centos project to recompile and revalidate all the packages and process. This is a well known issue of this process and I hope we can stay under 30 days if possible in order to keep the credibility of the project, and it seams there are some improvements under way to keep this goal. In that case, there is a gap of 10 to 90 days under which several security patches may be issued but not installed under our Centos servers. Once more, if we want the real upstream support, we have to buy it from upstream and not complain from centos. Once centos issue the new x.(y+1) version, we are back in case A). C) The new policy of centos x.y + security patches of upstream x.(y+1) In that case, we are in a situation where the system is not a x.y version and not a x.(y+1) version. At least we may get dependencies issues (for example cman/openais case), but also stability issues (for example new kernel with older user land tools). We get a system that is not in sync with upstream QA (the main reason people choose Centos is to be in sync with upstream QA without paying for it !). I understand that issuing the patches of upstream x.(y+1) to be installed under centos x.y is an attempts to close the gap of case B). But the problem is that the way you have done it will move all people from a well known state (A) to an unkown state (C) without warning. I think a better approach would have been to propose theses new security patch under an optional repository and not the update one. And don't misunderstand : I am very pleased with centos, and I just add my 2 cents in order to improve it ! Regards, -- Alain RICHARD <mailto:alain.richard at equation.fr> EQUATION SA <http://www.equation.fr/> Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL <http://www.e-liance.fr> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20090917/046015f6/attachment-0004.html>