- **status**: unassigned -- assigned
- **assigned_to**: Praveen
- **Milestone**: 4.3.3 -- 4.4.1
---
** [tickets:#1055] dependent si assignments are not removed**
**Status:** assigned
**Milestone:** 4.4.1
**Created:** Tue Sep 09, 2014 09:59 AM UTC by surender khetavath
**Last Updated:** Wed
- **status**: assigned -- duplicate
- **Milestone**: 4.4.1 -- never
- **Comment**:
Issue is reproducible and #1015 solves it. Hence marking it duplicate of #1015.
---
** [tickets:#1055] dependent si assignments are not removed**
**Status:** duplicate
**Milestone:** never
**Created:** Tue Sep
---
** [tickets:#1057] (2PBE) Slave PBE restarts multiple times**
**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Wed Sep 10, 2014 07:00 AM UTC by Sirisha Alla
**Last Updated:** Wed Sep 10, 2014 07:00 AM UTC
**Owner:** nobody
The issue is seen on SLES X86. Opensaf is up with
SC-2 logs
Attachment: SLOT2.tar.bz2 (28.3 MB; application/x-bzip)
---
** [tickets:#1057] (2PBE) Slave PBE restarts multiple times**
**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Wed Sep 10, 2014 07:00 AM UTC by Sirisha Alla
**Last Updated:** Wed Sep 10, 2014 07:00 AM UTC
SC-1 logs. Since the logs are very huge I tried to trim the immnd traces to the
timing of the issue
Attachment: SLOT1.tar.bz2 (1.6 MB; application/x-bzip)
---
** [tickets:#1057] (2PBE) Slave PBE restarts multiple times**
**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Wed Sep 10,
- **status**: unassigned -- accepted
- **assigned_to**: Anders Bjornerstedt
- **Milestone**: 4.3.3 -- 4.4.1
- **Comment**:
Is the test that provokes this problem a new test (recently introduced)
or is it an old test that has previously not provoked these problems?
2PBE was introduced in OpensF
---
** [tickets:#1058] AMF: error report notifications sent with alarm event type**
**Status:** unassigned
**Milestone:** 4.5.0
**Created:** Wed Sep 10, 2014 08:02 AM UTC by Hans Feldt
**Last Updated:** Wed Sep 10, 2014 08:02 AM UTC
**Owner:** nobody
- **status**: accepted -- review
---
** [tickets:#1050] amfnd sometimes fails to start due to ERR_LIBRARY from
saImmOmInitialize**
**Status:** review
**Milestone:** 4.5.0
**Created:** Tue Sep 09, 2014 07:08 AM UTC by Hans Feldt
**Last Updated:** Tue Sep 09, 2014 07:08 AM UTC
**Owner:** Hans
---
** [tickets:#1059] 2PBE: cluster reset observed during switchovers**
**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Wed Sep 10, 2014 09:57 AM UTC by Sirisha Alla
**Last Updated:** Wed Sep 10, 2014 09:57 AM UTC
**Owner:** nobody
The issue is seen on SLES X86. OpenSAF is running
SC-2 logs
Attachment: SLOT2.tar.bz2 (8.9 MB; application/x-bzip)
---
** [tickets:#1059] 2PBE: cluster reset observed during switchovers**
**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Wed Sep 10, 2014 09:57 AM UTC by Sirisha Alla
**Last Updated:** Wed Sep 10, 2014 09:57 AM UTC
---
** [tickets:#1060] AMF: reset of cluster startup timer does not happen (#76)**
**Status:** unassigned
**Milestone:** future
**Created:** Wed Sep 10, 2014 10:18 AM UTC by Hans Feldt
**Last Updated:** Wed Sep 10, 2014 10:18 AM UTC
**Owner:** nobody
When all SUs are ENABLED and
- **Component**: unknown -- clm
- **Comment**:
The direct cause of the cluster reset is that CLM exits on receiving
ERR_EXIST on implementerSet.This could a case of #946
(fixed in 5722:d353ca39b3d9).
If not then someone needs to analyze what CLM is doing (it is detaching as main
OI and fails
The CLM problem actually only explains why this SLOT2 went down.
This was a switchover, not a failover, so the other SC should have
reverted the switchover.
---
** [tickets:#1059] 2PBE: cluster reset observed during switchovers**
**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Wed
- **status**: review -- fixed
- **Comment**:
changeset: 5758:52212ecd4267
user:A V Mahesh mahesh.va...@oracle.com
date:Wed Sep 10 15:22:56 2014 +0530
summary: mds: send full encode message for Mcast message type [#1043]
changeset: 5759:383f556c0330
branch:
And one more comment:
I dont think that this incident is logically related to 2PBE.
A PRTO fails to get created.
That is possibly more likely to happen with 2PBE than 1PBE or 0PBE,
but logically it can at least also happen also with 1PBE.
---
** [tickets:#1059] 2PBE: cluster reset observed
- **status**: review -- fixed
- **Comment**:
changeset: 5760:8f303de00e27
branch: opensaf-4.5.x
user:Robert Apanowicz robert.apanow...@ericsson.com
date:Tue Sep 02 09:42:03 2014 +0200
summary: smf: set max DN length in SMF based on long DN config in IMM [#981]
---
** [tickets:#1061] imm: memory leak in dumping resources in PBE**
**Status:** unassigned
**Milestone:** 4.5.0
**Created:** Wed Sep 10, 2014 12:35 PM UTC by Zoran Milinkovic
**Last Updated:** Wed Sep 10, 2014 12:35 PM UTC
**Owner:** Zoran Milinkovic
In dumping resources (in PBE), data are
---
** [tickets:#1062] imm: immnd may crash in resourceDisplay**
**Status:** unassigned
**Milestone:** 4.5.0
**Created:** Wed Sep 10, 2014 02:10 PM UTC by Zoran Milinkovic
**Last Updated:** Wed Sep 10, 2014 02:10 PM UTC
**Owner:** Zoran Milinkovic
immnd may crash in immModel_resourceDisplay
A. SLOT1 node went down:
1. CLM got BAD_HANDLE and finalizes the handle
Sep 10 14:56:51.543332 osafclmd [7511:imma_oi_api.c:0622] saImmOiFinalize
Sep 10 14:56:51.543370 osafclmd [7511:imma_oi_api.c:0626] T2 ERR_BAD_HANDLE: No
initialized handle exists!
2. Discard implementer is called
Sep
Good analysis.
We can add that the reason that AMFD got BAD_HANLDE when attempting to do an
RtObjectUpdate is that
although the OI handle is valid, it was not associated with any
implementer-name at that time.
So this must be a pure and plain bug in the AMFD. Most likely recently
introduced
Good analysis.
We can add that the reason that AMFD got BAD_HANLDE when attempting to do an
RtObjectUpdate is that
although the OI handle is valid, it was not associated with any
implementer-name at that time.
So this must be a pure and plain bug in the AMFD. Most likely recently
introduced
Neel correctly points out that 946 may fix the CLM problem.
This is true if the ERR_EXIST on implementer-set is due to the prior OI having
detached *locally* at this node
but not yet been confirmed globally over fevs. But since this is a switchover,
it is more likley that the OI detached
on the
22 matches
Mail list logo