Hi Mahesh,
From our point of view this makes this solution not usable for us. It
is necessary that it works the same regardless if the underlying
protocol is TCP or TIPC and it must always work with all nodes. If
this can't be solved it means that we must use another solution for
the log service.
I suggest two alternatives where CLM is used to get the node name
based on the node id given via MDS:
1.
Fix CLM so that the initialize API can be used also before the
CLM server (director) is started. As is today the API call will
never return which makes the log service hang resulting in a nid
timeout. The reason for this is that clm initialize api waits for
node up for the clm server before returning. If this is changed
so that initialize instead returns with TRY AGAIN parts of the
problem is solved. If a log record is requested to be written
before CLM is started node id (as a string) could temporary be
used instead of node name.
2.
A better solution could be to make it possible to start CLM
before the log service. This is not possible for now since CLM
wants to use NTF which is dependent on LOG.
3.
And of course if the problem below somehow can be handled
Thanks
Lennart
From: A V Mahesh (AVM) [mailto:avmah...@users.sf.net]
Sent: den 27 januari 2016 08:27
To: opensaf-tickets@lists.sourceforge.net
Subject: [tickets]
<http://sourceforge.net/p/opensaf/tickets/_discuss/>
[opensaf:tickets] #1480 LOG: Extend information about origin of log
record
Please find the updated comments and it limitation in ticket #1522
MDS: Include node name as a part of control events
============================================================================
>>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
providing 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:#1480]
<http://sourceforge.net/p/opensaf/tickets/1480/>http://sourceforge.net/p/opensaf/tickets/1480/
LOG: Extend information about origin of log record
Status: accepted
Milestone: 5.0.FC
Created: Tue Sep 15, 2015 12:50 PM UTC by elunlen
Last Updated: Tue Dec 22, 2015 04:32 AM UTC
Owner: elunlen
Add the possibility to show network name and CLM node name or node id
as an extension of the already existing way of showing the origin of
a log record.
For a detailed description of what to implement see the attached .odt
document.
To show/document how this can be implemented the ticket will be
complimented with a series of prototype patches that will be attached
when ready
------------------------------------------------------------------------
Sent from sourceforge.net because
opensaf-tickets@lists.sourceforge.netopensaf-tick...@lists.sourceforge.net
<mailto:opensaf-tickets@lists.sourceforge.net> 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.
------------------------------------------------------------------------
*[tickets:#1480] <http://sourceforge.net/p/opensaf/tickets/1480/>
LOG: Extend information about origin of log record*
*Status:* accepted
*Milestone:* 5.0.FC
*Created:* Tue Sep 15, 2015 12:50 PM UTC by elunlen
*Last Updated:* Wed Jan 27, 2016 07:26 AM UTC
*Owner:* elunlen
Add the possibility to show network name and CLM node name or node id
as an extension of the already existing way of showing the origin of
a log record.
For a detailed description of what to implement see the attached .odt
document.
To show/document how this can be implemented the ticket will be
complimented with a series of prototype patches that will be attached
when ready
------------------------------------------------------------------------
Sent from sourceforge.net because
opensaf-tickets@lists.sourceforge.net is subscribed to
http://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change
settings at http://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
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
