[ClusterLabs] Coming in 1.1.15: Event-driven alerts

renayama19661014 at ybb.ne.jp renayama19661014 at ybb.ne.jp
Fri May 13 10:59:24 EDT 2016


i Klaus,

After all we want transmission order.
I think that I am going to use meta_attribute which you suggested and am enough.

(snip)
<alert id="alert-1"
path="/xxx/xxxx/xxxxxxx.sh">
<meta_attributes id="meta-alert-1-queue">
<nvpair id="alert-1-queue" name="queue" value="alert1-queue" />
</meta_attributes>
</alert>
<alert id="alert-2"
path="/xxx/xxxx/xxxxxxx.sh">

(snip)

I intend to write the correction that included a cue in this meta_attribute, what do you think?
I think that processing when queue was changed is troublesome, but think that I can write the patch somehow.

We intend to make the correction that pcmk_snmp_helper.shkeeps versatility.

We want to use this function in Pacemaker1.1.15.

Best Regards,
Hideo Yamauch.



----- Original Message -----
> From: "renayama19661014 at ybb.ne.jp" <renayama19661014 at ybb.ne.jp>
> To: "kwenning at redhat.com" <kwenning at redhat.com>; "users at clusterlabs.org" <users at clusterlabs.org>; Cluster Labs - All topics related to open-source clustering welcomed <users at clusterlabs.org>
> Cc: 
> Date: 2016/5/12, Thu 06:28
> Subject: Re: [ClusterLabs] Coming in 1.1.15: Event-driven alerts
> 
> Hi Klaus,
> 
> Thank you for comment.
> 
> I confirm your comment.
> I think that I ask you a question again.
> 
> 
> Many thanks!
> Hideo Yamauchi.
> 
> 
> ----- Original Message -----
>>  From: Klaus Wenninger <kwenning at redhat.com>
>>  To: users at clusterlabs.org
>>  Cc: 
>>  Date: 2016/5/11, Wed 14:13
>>  Subject: Re: [ClusterLabs] Coming in 1.1.15: Event-driven alerts
>> 
>>  On 05/10/2016 11:19 PM, renayama19661014 at ybb.ne.jp wrote:
>>>   Hi All,
>>> 
>>>   After all our member needs the control of the turn of the transmission 
> of 
>>  the SNMP trap.
>>> 
>>>   We make a patch of the control of the turn of the transmission and 
> intend 
>>  to send it.
>>> 
>>>   Probably, with the patch, we add the "ordered" attribute 
> that we 
>>  sent by an email before.
>>  Actually I still don't think that simple serialization of the calling 
> of
>>  the snmptrap-tool
>>  is a good solution to tackle the problem of loosing the order of traps
>>  arriving at
>>  some management station:
>> 
>>  - makes things worse in case of traps coming from multiple nodes
>>  - doesn't help when the order is lost on the network.
>> 
>>  Anyway I see 2 other scenarios where a certain degree of serialization 
> might
>>  be helpful:
>> 
>>  - alert agent-scripts that can't handle being called concurrently
>>  - performance issues that might arise on some systems that lack the
>>    performance-headroom needed and/or the agent-scripts in place
>>    require significant effort and/or there are a lot of resources/events
>>    that trigger a vast amount of alerts being handled in parallel
>> 
>>  So I could imagine the introduction of a meta-atribute that specifies a
>>  queue
>>  to be used for serialization.
>> 
>>  - 'none' is default and leads to the behavior we have at the 
> moment.
>>  - any other queue-name leads to the instantiation of an additional queue
>> 
>>  This approach should allow merely any kind of serialization you can think 
> of
>>  with as little impact as needed.
>>  e.g. if the agent doesn't cope with concurrent calls you use a queue 
> per
>>  agent leading to all recipients being handled in a serialized way (and of
>>  course the different alerts as well). And all the other agents are running
>>  in parallel.
>>  e.g. you can have a separate queue for a single recipient leading to
>>  the alerts being sent there being serialized.
>>  e.g. if the performance impact should be kept at a minimal level you
>>  would use a single queue for all agents and all recipients 
>> 
>>> 
>>> 
>>>   Best Regards,
>>>   Hideo Yamauchi.
>>> 
>>> 
>>>   ----- Original Message -----
>>>>   From: "renayama19661014 at ybb.ne.jp" 
>>  <renayama19661014 at ybb.ne.jp>
>>>>   To: "kwenning at redhat.com" <kwenning at redhat.com>; 
>>  "users at clusterlabs.org" <users at clusterlabs.org>; Cluster 
> Labs - 
>>  All topics related to open-source clustering welcomed 
>>  <users at clusterlabs.org>
>>>>   Cc: 
>>>>   Date: 2016/4/28, Thu 22:43
>>>>   Subject: Re: [ClusterLabs] Coming in 1.1.15: Event-driven alerts
>>>> 
>>>>   Hi Klaus,
>>>> 
>>>>   Because the script is performed the effectiveness of in async, I 
> think 
>>  that it 
>>>>   is difficult to set "uptime" by the method of the 
> sample.
>>>>   After all we may request the transmission of the order.
>>>>   #The patch before mine only controls a practice turn of the async 
> and 
>>  is not a 
>>>>   thing giving load of crmd.
>>>> 
>>>>   Japan begins a rest for one week from tomorrow.
>>>>   I discuss after vacation with a member.
>>>> 
>>>>   Best Regards,
>>>>   Hideo Yamauchi.
>>>> 
>>>> 
>>>> 
>>>>   ----- Original Message -----
>>>>>    From: Klaus Wenninger <kwenning at redhat.com>
>>>>>    To: users at clusterlabs.org
>>>>>    Cc: 
>>>>>    Date: 2016/4/28, Thu 03:14
>>>>>    Subject: Re: [ClusterLabs] Coming in 1.1.15: Event-driven 
> alerts
>>>>> 
>>>>>    On 04/27/2016 04:19 PM, renayama19661014 at ybb.ne.jp wrote:
>>>>>>     Hi All,
>>>>>> 
>>>>>>     We have a request for a new SNMP function.
>>>>>> 
>>>>>> 
>>>>>>     The order of traps is not right.
>>>>>> 
>>>>>>     The turn of the trap is not sometimes followed.
>>>>>>     This is because the handling of notice carries out 
>>  "path" in 
>>>>>    async.
>>>>>>     I think that it is necessary to wait for completion of 
> the 
>>  practice at 
>>>>>    "path" unit of "alerts".
>>>>>>      
>>>>>>     The turn of the trap is different from the real stop 
> order of 
>>  the 
>>>>   resource.
>>>>>    Writing the alerts in a local list and having the 
> alert-scripts 
>>  called
>>>>>    in a serialized manner
>>>>>    would lead to the snmptrap-tool creating timestamps in the 
> order 
>>  of the
>>>>>    occurrence 
>>>>>    of the alerts.
>>>>>    Having the snmp-manager order the traps by timestamp this 
> would 
>>  indeed
>>>>>    lead to
>>>>>    seeing them in the order they had occured.
>>>>> 
>>>>>    But this approach has a number of drawbacks:
>>>>> 
>>>>>    - it works just when the traps are coming from one node as 
> there 
>>  is no
>>>>>    way to serialize
>>>>>      over nodes - at least none that would work under all 
>>  circumstances we
>>>>>    want alerts
>>>>>      to be delivered
>>>>> 
>>>>>    - it distorts the timestamps created even more from the 
> points in 
>>  time
>>>>>    when the
>>>>>      alert had been triggered - making the result in a 
>>  multi-node-scenario
>>>>>    even worse and
>>>>>      making it hard to correlate with other sources of 
> information 
>>  like
>>>>>    logfiles
>>>>> 
>>>>>    - if you imagine a scenario with multiple mechanisms of 
> delivering 
>>  an
>>>>>    alert + multiple
>>>>>      recipients we couldn't use a single list but we would 
> need 
>>  something 
>>>>   more
>>>>>      complicated to prevent unneeded delays, delays coming from 
> one 
>>  of the
>>>>>    delivery
>>>>>      methods not working properly due to e.g. a recipient that 
> is not
>>>>>    reachable, ...
>>>>>      (all solvable of course but if it doesn't solve your 
> problem 
>>  in the
>>>>>    first place why the effort)
>>>>> 
>>>>>    The alternative approach taken doesn't create the 
> timestamps 
>>  in the
>>>>>    scripts but
>>>>>    provides timestamps to the scripts already.
>>>>>    This way it doesn't matter if the execution of the script 
> is 
>>  delayed.
>>>>> 
>>>>> 
>>>>>    A short example how this approach could be used with 
> snmp-traps:
>>>>> 
>>>>>    edit pcmk_snmp_helper.sh:
>>>>> 
>>>>>    ...
>>>>>    starttickfile="/var/run/starttick"
>>>>> 
>>>>>    # hack to have a reference
>>>>>    # can have it e.g. in an attribute to be visible throughout 
> the 
>>  cluster
>>>>>    if [ ! -f ${starttickfile} ] ; then
>>>>>            echo ${CRM_alert_timestamp} > ${starttickfile}
>>>>>    fi
>>>>> 
>>>>>    starttick=`cat ${starttickfile}`
>>>>>    ticks=`eval ${CRM_alert_timestamp} - ${starttick}`
>>>>> 
>>>>>    if [[ ${CRM_alert_rc} != 0 && ${CRM_alert_task} == 
>>>>   "monitor" 
>>>>>    ]] || [[
>>>>>    ${CRM_alert_task} != "monitor" ]] ; then
>>>>>        # This trap is compliant with PACEMAKER MIB
>>>>>        # 
>>>>>    
>>  https://github.com/ClusterLabs/pacemaker/blob/master/extra/PCMK-MIB.txt
>>>>>        /usr/bin/snmptrap -v 2c -c public ${CRM_alert_recipient} 
>>  ${ticks}
>>>>>    PACEMAKER-MIB::pacemakerNotificationTrap \
>>>>>            PACEMAKER-MIB::pacemakerNotificationNode s 
>>>>   "${CRM_alert_node}" 
>>>>>    \
>>>>>            PACEMAKER-MIB::pacemakerNotificationResource s 
>>>>>    "${CRM_alert_rsc}" \
>>>>>            PACEMAKER-MIB::pacemakerNotificationOperation s
>>>>>    "${CRM_alert_task}" \
>>>>>            PACEMAKER-MIB::pacemakerNotificationDescription s
>>>>>    "${CRM_alert_desc}" \
>>>>>            PACEMAKER-MIB::pacemakerNotificationStatus i 
>>>>>    "${CRM_alert_status}" \
>>>>>            PACEMAKER-MIB::pacemakerNotificationReturnCode i 
>>  ${CRM_alert_rc} 
>>>>   \
>>>>>            PACEMAKER-MIB::pacemakerNotificationTargetReturnCode 
> i
>>>>>    ${CRM_alert_target_rc} && exit 0 || exit 1
>>>>>    fi
>>>>> 
>>>>>    exit 0
>>>>>    ...
>>>>> 
>>>>>    add a section to the cib:
>>>>> 
>>>>>    cibadmin --create --xml-text '<configuration> 
>>  <alerts> 
>>>>   <alert
>>>>>    id="snmp_traps" 
>>>>>    
>>  path="/usr/share/pacemaker/tests/pcmk_snmp_helper.sh">
>>>>>    <meta_attributes id="meta_snmp_traps"> 
> <nvpair 
>>>>>    id="snmp_timestamp"
>>>>>    name="tstamp_format" value="%s%02N"/> 
>>>>>    </meta_attributes> <recipient
>>>>>    id="trap_destination" 
>>  value="192.168.123.3"/> 
>>>>>    </alert> </alerts>
>>>>>    </configuration>'
>>>>> 
>>>>> 
>>>>>    This should solve the issue of correct order after being 
> sorted by
>>>>>    timestamps
>>>>>    without having the ugly side-effects as described above.
>>>>> 
>>>>>    I hope I understood your scenario correctly and this small 
> example
>>>>>    points out how I roughly would suggest to cope with the 
> issue.
>>>>> 
>>>>>    Regards,
>>>>>    Klaus  
>>>>>>     ----
>>>>>>     [root at rh72-01 ~]# grep Operation  /var/log/ha-log | grep 
> stop
>>>>>>     Apr 25 18:48:48 rh72-01 crmd[28897]:  notice: Operation 
>>>>   prmDummy1_stop_0: 
>>>>>    ok (node=rh72-01, call=33, rc=0, cib-update=56, 
> confirmed=true)
>>>>>>     Apr 25 18:48:48 rh72-01 crmd[28897]:  notice: Operation 
>>>>   prmDummy3_stop_0: 
>>>>>    ok (node=rh72-01, call=37, rc=0, cib-update=57, 
> confirmed=true)
>>>>>>     Apr 25 18:48:48 rh72-01 crmd[28897]:  notice: Operation 
>>>>   prmDummy4_stop_0: 
>>>>>    ok (node=rh72-01, call=39, rc=0, cib-update=58, 
> confirmed=true)
>>>>>>     Apr 25 18:48:48 rh72-01 crmd[28897]:  notice: Operation 
>>>>   prmDummy2_stop_0: 
>>>>>    ok (node=rh72-01, call=35, rc=0, cib-update=59, 
> confirmed=true)
>>>>>>     Apr 25 18:48:48 rh72-01 crmd[28897]:  notice: Operation 
>>>>   prmDummy5_stop_0: 
>>>>>    ok (node=rh72-01, call=41, rc=0, cib-update=60, 
> confirmed=true)
>>>>>>     Apr 25 18:48:50 snmp-manager snmptrapd[6865]: 2016-04-25 
> 
>>  18:48:50 
>>>>>    <UNKNOWN> [UDP: 
>>>>> 
>>>> 
>> 
> [192.168.28.170]:40613->[192.168.28.189]:162]:#012DISMAN-EVENT-MIB::sysUpTimeInstance 
> 
>> 
>>>> 
>>>>>    = Timeticks: (25512486) 2 days, 
>>  22:52:04.86#011SNMPv2-MIB::snmpTrapOID.0 = 
>>>>   OID: 
>>>> 
>> 
> PACEMAKER-MIB::pacemakerNotificationTrap#011PACEMAKER-MIB::pacemakerNotificationNode 
> 
>> 
>>>> 
>>>>>    = STRING: 
>>>>   
> "rh72-01"#011PACEMAKER-MIB::pacemakerNotificationResource = 
>>>>>    STRING: 
>>>>   
> "prmDummy3"#011PACEMAKER-MIB::pacemakerNotificationOperation 
>>  = 
>>>>>    STRING: 
>>  "stop"#011PACEMAKER-MIB::pacemakerNotificationDescription 
>>>>   = 
>>>>>    STRING: 
>>  "ok"#011PACEMAKER-MIB::pacemakerNotificationStatus = 
>>>>   INTEGER: 
>>>>>    0#011PACEMAKER-MIB::pacemakerNotificationReturnCode = 
> INTEGER: 
>>>>>    0#011PACEMAKER-MIB::pacemakerNotificationTargetReturnCode = 
>>  INTEGER: 0
>>>>>>     Apr 25 18:48:50 snmp-manager snmptrapd[6865]: 2016-04-25 
> 
>>  18:48:50 
>>>>>    <UNKNOWN> [UDP: 
>>>>> 
>>>> 
>> 
> [192.168.28.170]:39581->[192.168.28.189]:162]:#012DISMAN-EVENT-MIB::sysUpTimeInstance 
> 
>> 
>>>> 
>>>>>    = Timeticks: (25512489) 2 days, 
>>  22:52:04.89#011SNMPv2-MIB::snmpTrapOID.0 = 
>>>>   OID: 
>>>> 
>> 
> PACEMAKER-MIB::pacemakerNotificationTrap#011PACEMAKER-MIB::pacemakerNotificationNode 
> 
>> 
>>>> 
>>>>>    = STRING: 
>>>>   
> "rh72-01"#011PACEMAKER-MIB::pacemakerNotificationResource = 
>>>>>    STRING: 
>>>>   
> "prmDummy4"#011PACEMAKER-MIB::pacemakerNotificationOperation 
>>  = 
>>>>>    STRING: 
>>  "stop"#011PACEMAKER-MIB::pacemakerNotificationDescription 
>>>>   = 
>>>>>    STRING: 
>>  "ok"#011PACEMAKER-MIB::pacemakerNotificationStatus = 
>>>>   INTEGER: 
>>>>>    0#011PACEMAKER-MIB::pacemakerNotificationReturnCode = 
> INTEGER: 
>>>>>    0#011PACEMAKER-MIB::pacemakerNotificationTargetReturnCode = 
>>  INTEGER: 0
>>>>>>     Apr 25 18:48:50 snmp-manager snmptrapd[6865]: 2016-04-25 
> 
>>  18:48:50 
>>>>>    <UNKNOWN> [UDP: 
>>>>> 
>>>> 
>> 
> [192.168.28.170]:37166->[192.168.28.189]:162]:#012DISMAN-EVENT-MIB::sysUpTimeInstance 
> 
>> 
>>>> 
>>>>>    = Timeticks: (25512490) 2 days, 
>>  22:52:04.90#011SNMPv2-MIB::snmpTrapOID.0 = 
>>>>   OID: 
>>>> 
>> 
> PACEMAKER-MIB::pacemakerNotificationTrap#011PACEMAKER-MIB::pacemakerNotificationNode 
> 
>> 
>>>> 
>>>>>    = STRING: 
>>>>   
> "rh72-01"#011PACEMAKER-MIB::pacemakerNotificationResource = 
>>>>>    STRING: 
>>>>   
> "prmDummy1"#011PACEMAKER-MIB::pacemakerNotificationOperation 
>>  = 
>>>>>    STRING: 
>>  "stop"#011PACEMAKER-MIB::pacemakerNotificationDescription 
>>>>   = 
>>>>>    STRING: 
>>  "ok"#011PACEMAKER-MIB::pacemakerNotificationStatus = 
>>>>   INTEGER: 
>>>>>    0#011PACEMAKER-MIB::pacemakerNotificationReturnCode = 
> INTEGER: 
>>>>>    0#011PACEMAKER-MIB::pacemakerNotificationTargetReturnCode = 
>>  INTEGER: 0
>>>>>>     Apr 25 18:48:50 snmp-manager snmptrapd[6865]: 2016-04-25 
> 
>>  18:48:50 
>>>>>    <UNKNOWN> [UDP: 
>>>>> 
>>>> 
>> 
> [192.168.28.170]:53502->[192.168.28.189]:162]:#012DISMAN-EVENT-MIB::sysUpTimeInstance 
> 
>> 
>>>> 
>>>>>    = Timeticks: (25512494) 2 days, 
>>  22:52:04.94#011SNMPv2-MIB::snmpTrapOID.0 = 
>>>>   OID: 
>>>> 
>> 
> PACEMAKER-MIB::pacemakerNotificationTrap#011PACEMAKER-MIB::pacemakerNotificationNode 
> 
>> 
>>>> 
>>>>>    = STRING: 
>>>>   
> "rh72-01"#011PACEMAKER-MIB::pacemakerNotificationResource = 
>>>>>    STRING: 
>>>>   
> "prmDummy2"#011PACEMAKER-MIB::pacemakerNotificationOperation 
>>  = 
>>>>>    STRING: 
>>  "stop"#011PACEMAKER-MIB::pacemakerNotificationDescription 
>>>>   = 
>>>>>    STRING: 
>>  "ok"#011PACEMAKER-MIB::pacemakerNotificationStatus = 
>>>>   INTEGER: 
>>>>>    0#011PACEMAKER-MIB::pacemakerNotificationReturnCode = 
> INTEGER: 
>>>>>    0#011PACEMAKER-MIB::pacemakerNotificationTargetReturnCode = 
>>  INTEGER: 0
>>>>>>     Apr 25 18:48:50 snmp-manager snmptrapd[6865]: 2016-04-25 
> 
>>  18:48:50 
>>>>>    <UNKNOWN> [UDP: 
>>>>> 
>>>> 
>> 
> [192.168.28.170]:45956->[192.168.28.189]:162]:#012DISMAN-EVENT-MIB::sysUpTimeInstance 
> 
>> 
>>>> 
>>>>>    = Timeticks: (25512497) 2 days, 
>>  22:52:04.97#011SNMPv2-MIB::snmpTrapOID.0 = 
>>>>   OID: 
>>>> 
>> 
> PACEMAKER-MIB::pacemakerNotificationTrap#011PACEMAKER-MIB::pacemakerNotificationNode 
> 
>> 
>>>> 
>>>>>    = STRING: 
>>>>   
> "rh72-01"#011PACEMAKER-MIB::pacemakerNotificationResource = 
>>>>>    STRING: 
>>>>   
> "prmDummy5"#011PACEMAKER-MIB::pacemakerNotificationOperation 
>>  = 
>>>>>    STRING: 
>>  "stop"#011PACEMAKER-MIB::pacemakerNotificationDescription 
>>>>   = 
>>>>>    STRING: 
>>  "ok"#011PACEMAKER-MIB::pacemakerNotificationStatus = 
>>>>   INTEGER: 
>>>>>    0#011PACEMAKER-MIB::pacemakerNotificationReturnCode = 
> INTEGER: 
>>>>>    0#011PACEMAKER-MIB::pacemakerNotificationTargetReturnCode = 
>>  INTEGER: 0
>>>>>>     ----
>>>>>> 
>>>>>>     I think that there is "timestamp" attribute 
> for 
>>  async by 
>>>>   this 
>>>>>    change.
>>>>>>     The order of traps may be important to a user.
>>>>>>     I suggest addition to "alert" element with 
>>>>   "orderd" 
>>>>>    attribute.
>>>>>>      * orderd 
>>>>>>         false : The present processing.
>>>>>>         true  : Control the transmission order of the trap.
>>>>>> 
>>>>>>     ----
>>>>>>     <configuration>
>>>>>>       <alerts>
>>>>>>         <alert id="notify_9"
>>>>>>    
>>  path="/usr/share/pacemaker/tests/pcmk_alert_sample1.sh" 
>>>>>    ordered="true">
>>>>>>     (snip)
>>>>>>         </alert>
>>>>>>         <alert id="notify_9"
>>>>>>    
>>  path="/usr/share/pacemaker/tests/pcmk_alert_sample2.sh" 
>>>>>    ordered="false">
>>>>>>     (snip)
>>>>>>         </alert>
>>>>>>       </alerts>
>>>>>>     </configuration>
>>>>>> 
>>>>>>     ----
>>>>>> 
>>>>>>     I send a patch to cope with this problem before.
>>>>>>     The former patch may be useful for the correction.
>>>>>>      * https://github.com/ClusterLabs/pacemaker/pull/847
>>>>>> 
>>>>>>     I intend to write the patch if everybody agrees to 
>>  "ordered" 
>>>>>    attribute.
>>>>>>     Best Regards,
>>>>>>     Hideo Yamauchi.
>>>>>> 
>>>>>>     _______________________________________________
>>>>>>     Users mailing list: Users at clusterlabs.org
>>>>>>    http://clusterlabs.org/mailman/listinfo/users
>>>>>> 
>>>>>>     Project Home: http://www.clusterlabs.org
>>>>>>     Getting started: 
>>>>   http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>>>>>     Bugs: http://bugs.clusterlabs.org
>>>>> 
>>>>>    _______________________________________________
>>>>>    Users mailing list: Users at clusterlabs.org
>>>>>    http://clusterlabs.org/mailman/listinfo/users
>>>>> 
>>>>>    Project Home: http://www.clusterlabs.org
>>>>>    Getting started: 
>>  http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>>>>    Bugs: http://bugs.clusterlabs.org
>>>>> 
>>>>   _______________________________________________
>>>>   Users mailing list: Users at clusterlabs.org
>>>>   http://clusterlabs.org/mailman/listinfo/users
>>>> 
>>>>   Project Home: http://www.clusterlabs.org
>>>>   Getting started: 
>>  http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>>>   Bugs: http://bugs.clusterlabs.org
>>>> 
>>>   _______________________________________________
>>>   Users mailing list: Users at clusterlabs.org
>>>   http://clusterlabs.org/mailman/listinfo/users
>>> 
>>>   Project Home: http://www.clusterlabs.org
>>>   Getting started: 
> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>>   Bugs: http://bugs.clusterlabs.org
>> 
>> 
>>  _______________________________________________
>>  Users mailing list: Users at clusterlabs.org
>>  http://clusterlabs.org/mailman/listinfo/users
>> 
>>  Project Home: http://www.clusterlabs.org
>>  Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>  Bugs: http://bugs.clusterlabs.org
>> 
> 
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
> 




More information about the Users mailing list