- **Comment**:
Hi All,
>>It can be noted that currently the MDS NODE_UP event is one of the evidences
>>that CLM
>>uses to determine and permit a node to join the cluster.
>>Currently node_id and ipaddress information is sent as a part of NODE_UP
>>event.
This is absolutely right in case TCP/MDS transport, currently we re providing
ipaddress information for TCP/MDS for TIPC/MDS UP event is provind NULL.
>>[It appears that sending node_name as a part of service up event (i.e. SVC_UP
>>event )
>> is more straightforward from the MDS user's perspective, but needs more
>> study]
Providing node_name as a part of NODE_UP/SVC_UP event can be completely
implementable/supportable in case of TCP/MDS transport ( including local &
remote node NODE_UP/SVC_UP even) , but providing node_name as a part of
NODE_UP/SVC_UP event is partially implementable/supportable in case of
TIPC/MDS transport ( only for local node NODE_UP/SVC_UP even)
This is because of in case of TCP/MDS Discovery sharing system name as part
of discovery is control of DTM in other hand TIPC/MDS Discovery TIPC_PUBLISHED
event cannot accommodate the system name as part f `tipc_event` and it is not
control of MDS ,
but we can only include local node name for LOCAL NODE_UP/SVC_UP up on
receiving TIPC_PUBLISHED event ( Local node name will be read as part of MDS
initialization when TIPC is transport)
struct tipc_event {
__u32 event; /* event type */
__u32 found_lower; /* matching name seq instances */
__u32 found_upper; /* " " " " */
struct tipc_portid port; /* associated port */
struct tipc_subscr s; /* associated subscription */
};
For example , TCP/MDS you will get node_name as follows :
-----------------------------------------------------------------------------
Jan 22 11:35:14 SC-1 osafclmd[15163]: ER MDTM: ===========> NODE_UP for
node_name: "PL-3", node_ip:192.168.56.103, node_id:131855 addr_family:2
msg_type:3
Jan 22 11:35:14 SC-1 osafclmd[15163]: ER MDTM: ===========> NODE_UP for
node_name: "SC-2", node_ip:192.168.56.102, node_id:131599 addr_family:2
msg_type:3
Jan 22 11:35:14 SC-1 osafclmd[15163]: ER MDTM: ===========> NODE_UP for
node_name: "SC-1", node_ip:192.168.56.101, node_id:131343 addr_family:2
msg_type:3
For example , TIPC/MDS you will get node_name as follows :
------------------------------------------------------------------------------
Jan 22 12:01:52 SC-1 osafclmd[22440]: ER MDTM: ===========> NODE_UP for
node_name: "SC-1", node_id:131343 addr_family:30
Jan 22 12:01:52 SC-1 osafclmd[22440]: ER MDTM: ===========> NODE_UP for
node_name: "UNKNOWN", node_id:131599 addr_family:30
Jan 22 12:01:52 SC-1 osafclmd[22440]: ER MDTM: ===========> NODE_UP for
node_name: "UNKNOWN", node_id:131855 addr_family:30
---
** [tickets:#1522] MDS: Include node name as a part of control events**
**Status:** accepted
**Milestone:** 5.0.FC
**Created:** Tue Oct 06, 2015 03:20 PM UTC by Mathi Naickan
**Last Updated:** Tue Dec 15, 2015 08:30 AM UTC
**Owner:** A V Mahesh (AVM)
It can be noted that currently the MDS NODE_UP event is one of the evidences
that CLM uses to determine and permit a node to join the cluster. Currently
node_id and ipaddress information is sent as a part of NODE_UP event.
However, it is now desired to send node_name also as a part of the MDS control
events for use in the following two scenarios:
a) CLM uses this as additional information to correlate NODE_UP event. i.e. CLM
can match node_name(part of NODE_UP) configured on that with the node_name
configured in the imm.xml. (This will be additional check on top of what CLMNA
provides ofcourse)
b) Some services that are started before CLM(like LOG service has come up with
a case #1480) require to know about node_name for logging the origination
information. This information has to be ideally read using CLM APIs but that is
not possible in scenarios when the membership of a node has not yet been
decided or this information will not be retrievable for logging activities that
takes place during the time when the cluster formation/synchronization is still
in progress.
It has to be seen whether MDS can send node_name as a part of standard MDS
header or as a part of MDS service up event (SVC_UP event) or as a part of MDS
NODE_UP event.
[It appears that sending node_name as a part of service up event (i.e. SVC_UP
event ) is more straightforward from the MDS user's perspective, but needs more
study]
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
