On Wed, 2007-11-28 at 09:47 -0800, Scott Becker wrote:|
Kevin Anderson wrote:
Not sure what you mean by 3 to 1 using IP tie breaker. How are you maintaining quorum without qdisk as a voting entity?
Also, you mention lingering issues about openais, but didn't see anything in your posts that describe any problems in that space. Can you be more specific?During network partition test, expecting a fencing race where I control the outcome, one node would not fence the other and did not takeover the service until the other node attempted to rejoin the cluster (way too late).
Is this resolved with the 5.1 release we did a few weeks ago?
Doubtful. There have been issues with cisco switch configurations with allowing multicast properly. All of those have been resolved with a switch configuration setting change.
Good point. Our community interface (ie sources.redhat.com) is pretty weak and needs revamping. Are you thinking blogs, wiki, etc? Also, our assumption is people accessing the community pages and mailing lists are developers, open source contributors, nonpaying consumers versus direct paying customers. Responses on the mailing lists, while pretty frequent can be spotty. Paying customers usually contact support directly rather than wait on developer responses.
Debugging mode option at the top of cluster.conf which will cause "Every" component to verbosely contribute to a separate log file which can be sent in to to be analyzed. A limited community size because of the niche nature of the system, calls for extra debugging effort.Good suggestion and one to look into providing. We did add the ability to centralize log messages in openais, but haven't incorporated that support into the commands/utilities as of yet.
We have an internal bugzilla for this one already, will see if product management can open it up for external viewing (ie not sure why it is locked at the moment).
An interactive design document for Cluster Suite where users can make suggestions for changes and vote for new features. In the process of exploring ways to get my setup working I kept finding ways and roadblocks. It's an involved product and process and I personally don't have any way to contribute to a design discussion.Currently community development discussion happens on cluster-devel mailing list, #linux-cluster irc freenode net and through bugzilla updates.
However, we don't have good records of which things are actively getting worked, versus areas where people can jump in and won't feel redundant. This also points out that we haven't had a cluster summit for a couple of years, which is also a way we coordinated/communicated effort and direction. Probably time to do that again as well as revamping our web interface.
Not the only one, which is why we probably didn't respond. ssh support needs to be added uniquely to each fence agent since it isn't just connecting, but also using the commands unique to each fencing device once you get access. Just doing a quick bugzilla search shows:
This is definitely support we are working on. Again, we should include in roadmap/priorities/vision page so people know it.
Both of these are part of the bigger picture resource monitoring work that Lon and some of the linux ha guys are jointly working on converging to a single base. See this page -
Which again, not very visible :-(.
So, my take aways:
1. For your environment and the current product, fence device access is insecure and needs to be on an internal private network. SSH specific fence device support is on the list of work items, but is dependent on getting time/resources to do them. Even then, it should still be on an internal private network.
2. Need better community pages - revamp/move website, add blogging, wiki, regular updates, more communication, roadmaps, etc... Purpose is to allow more community communication and participation.
3. Time for Cluster Summit again - location preferences, timeframe, funding, etc?