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:[email protected]]
Sent: den 27 januari 2016 08:27
To: [email protected]
Subject: [tickets] [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/> 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
[email protected]<mailto:[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.
---
** [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 [email protected] 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
