[Openais] call for roadmap features for future releases

Steven Dake sdake at redhat.com
Thu Jun 25 23:53:16 PDT 2009


On Fri, 2009-06-26 at 14:23 +0900, Keisuke MORI wrote:
> Dear Steve,
> 
> 2009/6/21 Steven Dake <sdake at redhat.com>:
> > I invite all of our contributors to help define the X.Y roadmap of both
> > corosync and openais.  Please submit your ideas on this list.  Some
> > examples of suggested ideas have been things like converting to libtool.
> > Also new service engine ideas are highly welcome.  Keep ideas within a 1
> > month - 3 year timeframe.
> 
> I'm going to migrate from Heartbeat-2.* stack to Pacemaker +
> OpenAIS/Corosync stack but found some features are missing.
> I would appreciate if you could consider those items:
> 
> 
> 1) Notification/diagnosis of the link status of each rings when it's
> down and up.
>    Currently, corosync-cfgtool -s reports "FAULTY" status when the
> first ring was down (which is good so far),  but will never report it
> when the second ring was failed.
>    It's very confusing for an operator to get to know which interfaces
> need to be repaired.
>    The operator also wants to be notified the status change by the
> syslog, but it's not obvious in the current log messages.
> 

roadmapped

> 
> 2) "Self-healing" of the network failure.
>    There was a discussion about it in this list recently. I would +1 for it.
> 
> 
roadmapped

> 3) SNMP notification.
>    The events of the status change like 1), 2) also need to be
> notified by SNMP traps to cooperate with management tools (such as
> Nagios etc.).
> 
> 
roadmapped

> 4) Log level separation.
>    The log messages should be categorised by its significance from the
> operator's point of view. For example:
>    a) WARN/ERROR: A failure or an important event that should be
> notified to the operator so that they can take an appropriate action.
>    b) INFO or lower: The internal cluster logs which is useful to
> diagnose the details of the cause for a cluster engineer (like you
> guys).
> 

We have a great infrastructure for this, but need to go through all the
log messages and set their priority appropriately.  a definate todo.
> 
> 5) Suicide when the internal process failed.
>    Heartbeat uses /dev/watchdog to react to the cluster process failure.
> 

good idea - i'll add it to the roadmap.

> 
> 6) "respawn" feature (sub processes management feature).
>    It would be useful when you want to add an additional service as a
> separated process.
>    An example usage is the SNMP feature 3) if it's implemented as a
> daemon. You can just add "respawn" configuration with the path to the
> daemon to enable it.
> 

i prefer corosync to remain as one process.

> 
> I'm glad to help you to implement any of those items if there's
> anything I can do.
> 
> Sincerely,



More information about the Openais mailing list