On Thu, Nov 15, 2012 at 11:02 AM, Robinson, Eric <[email protected]> wrote: >> I can think of 3 tooling changes: >> >> - ptest/crm_simulate >> - hb_report/crm_report >> - standalone crmsh >> >> Thats not /too/ bad in 4 years. >> > > Fair enough. From my perspective, I was thinking of the fact that our first > cluster was rolled out in 2006, back when the documentation was all about > paul and silas. We now have production clusters that fall into 3 major > branches: monolithic heartbeat, heartbeat+pacemaker, corosync+pacemaker. When > I rolled out my first cluster, conventional wisdom held that a secondary > heartbeat channel via serial cable was a good idea. It was right there in the > docs! By the time I rolled out my second or third, that idea was scorned, and > understandably so. I kind of liked the heartbeat cluster membership layer, so > I was initially hesitant to move to corosync. Then there was some sort of > brouhaha over what would and would not be supported under RHEL, so here I am > a few years later with several cluster styles (R1, R2), different stacks and > a cornucopia of technologies and tools to keep in my head.
No argument that this is not ideal. > It's been quite a moving target from my standpoint. Don't think I'm > disappointed with the results > , mind you. I'd rather struggle with the changes than pursue some of the > alternatives. But I would dance a jig if there was a single, unified > clearinghouse for downloads and up-to-date documentation. clusterlabs.org/doc is as good as i can do for docs. i try to keep it up-to-date and version specific (so that documenting corosync 2.x doesn't obliterate the cman/plugin stuff). packages are mostly in the hands of the distros though. building the entire stack (and keeping it up-to-date) on all the major distros is a massive job - i'd never get any actual work done. and typically not easy unless you work for the enterprise distro you're building for. > Just getting my most recent cluster up and running has been an interesting > exercise, what with stuff coming from clusterlabs, clusterlabs-next, github, > scientific linux, and other places. And I'm still not there. In theory you should at most need "scientific linux" (even clusterlabs.org/rpm-next is somewhat optional) + your choice of shell/gui. > This latest cluster is finally working, mostly, except the dang thing wont > failover my drbd master-slave pairs. > > --Eric > > > > > > > > > > > > > Disclaimer - November 14, 2012 > This email and any files transmitted with it are confidential and intended > solely for General Linux-HA mailing list. If you are not the named addressee > you should not disseminate, distribute, copy or alter this email. Any views > or opinions presented in this email are solely those of the author and might > not represent those of Physicians' Managed Care or Physician Select > Management. Warning: Although Physicians' Managed Care or Physician Select > Management has taken reasonable precautions to ensure no viruses are present > in this email, the company cannot accept responsibility for any loss or > damage arising from the use of this email or attachments. > This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
