> -Original Message-
> From: Hans Feldt [mailto:hans.fe...@ericsson.com]
> Sent: Monday, November 18, 2013 9:47 PM
> To: Mathivanan Naickan Palanivelu; Nagendra Kumar
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: RE: [devel] [PATCH 1 of 1] amfnd: Reboot payload when link
> between Co
> -Original Message-
> From: Mathivanan Naickan Palanivelu [mailto:mathi.naic...@oracle.com]
> Sent: den 18 november 2013 14:05
> To: Hans Feldt; Nagendra Kumar
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: RE: [devel] [PATCH 1 of 1] amfnd: Reboot payload when link between
> Contr
Hi Carl, the IMM_A_01_01 should be removed and some whitespace issues to be
fixed, e.g. at line 576. Otherwise it looked ok/BR HansN
-Original Message-
From: Carl Johannesson
Sent: den 18 november 2013 11:14
To: Hans Nordebäck
Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 1 of
I am ok in not supporting this use case.
The IMMND is only upgraded in conjunction with a whole new release of a
deployment of OpenSAF.
/AndersBj
Nagendra Kumar wrote:
> Hi Anders,
>
> As described by Bertil, the use case for component restart for upgrade could
> be used for immnd upgrade also
That use case has never been described thought of until now...
Upgrading opensaf should be done by:
0) lock AMF node
1) stop opensaf
2) upgrade opensaf
3) start opensaf
4) unlock AMF node
Where 0 & 4 being optional, it would work anyway but with application failovers
instead of switch-over.
So
Comments inline:
> -Original Message-
> From: Hans Feldt [mailto:hans.fe...@ericsson.com]
> Sent: Monday, November 18, 2013 5:53 PM
> To: Mathivanan Naickan Palanivelu; Nagendra Kumar
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: RE: [devel] [PATCH 1 of 1] amfnd: Reboot payload when
Hi Anders,
As described by Bertil, the use case for component restart for upgrade could be
used for immnd upgrade also.
For example, if user want to patch a critical fix in immnd, it is easy to
upgrade only immnd by making component restart.
If you are ok to not support this use case, then we c
> -Original Message-
> From: Mathivanan Naickan Palanivelu [mailto:mathi.naic...@oracle.com]
> Sent: den 18 november 2013 11:07
> To: Hans Feldt; Nagendra Kumar
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: RE: [devel] [PATCH 1 of 1] amfnd: Reboot payload when link between
> Contro
python/pyosaf/saImmOm.py | 391 --
1 files changed, 334 insertions(+), 57 deletions(-)
Add declaration of argtypes/restype for
all functions.
diff --git a/python/pyosaf/saImmOm.py b/python/pyosaf/saImmOm.py
--- a/python/pyosaf/saImmOm.py
+++ b/python
Summary: immom/pyosaf: Fix saImmOm.py [#626]
Review request for Trac Ticket(s): <>
Peer Reviewer(s): Hans N
Pull request to: <>
Affected branch(es): 4.4
Development branch: default
Impacted area Impact y/n
Docs
Comments inline:
> -Original Message-
> From: Hans Feldt [mailto:hans.fe...@ericsson.com]
> Sent: Monday, November 18, 2013 3:09 PM
> To: SuryaNarayana Garlapati
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: Re: [devel] [PATCH 1 of 1] amfnd: Reboot payload when link
> between Contro
>From an OpenSAF architecture perspective, FM is designated to orchestrate
>controller failover.
Comments inline:
> -Original Message-
> From: Hans Feldt [mailto:hans.fe...@ericsson.com]
> Sent: Monday, November 18, 2013 2:42 PM
> To: Nagendra Kumar; Mathivanan Naickan Palanivelu
> Cc: op
Any response on this ticket ?
Thanks
-Nagu
-Original Message-
From: Nagendra Kumar
Sent: 15 November 2013 12:32
To: hans.nordeb...@ericsson.com (h...@acsinet22.oracle.com); Hans Feldt
(hans.fe...@ericsson.com)
Cc: opensaf-devel@lists.sourceforge.net
Subject: [devel] FW: [PATCH 1 of 1] a
>>* The MDS thread is changing data in the control block. It should only send a
>>message to the main thread.
Since the flow of TIPC flicker and node failover happening is two different
incidents, so they are not going to contend for variable in MDS thread and AmfD
thread. I don't find any othe
> -Original Message-
> From: SuryaNarayana Garlapati [mailto:suryanarayana.garlap...@oracle.com]
> Sent: den 18 november 2013 10:19
> To: Hans Feldt
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: Re: [devel] [PATCH 1 of 1] amfnd: Reboot payload when link between
> Controller and Pay
If you want to upgrade immnd only and not other middleware components like any
other applications upgrade, then we can't upgrade immnd if the component type
is changed.
Thanks
-Nagu
-Original Message-
From: Anders Björnerstedt [mailto:anders.bjornerst...@ericsson.com]
Sent: 18 November
Hi Hans,
Can you please check whether we are in sync with the
approaches(Please check my comments inlined with [Nagu]).
Thanks
-Nagu
-Original Message-
From: Nagendra Kumar
Sent: 18 November 2013 12:22
To: Hans Feldt; Hans Nordebäck; Anders Björnerstedt
Cc: opensaf-devel
The IMMND is at least restartable.
But I still dont understand what the upgrade of the IMMND would be for.
/AndersBj
-Original Message-
From: Bertil Engelholm
Sent: den 18 november 2013 10:02
To: Anders Björnerstedt; Nagendra Kumar; Hans Feldt; Hans Nordebäck
Cc: opensaf-devel@lists.sou
On Monday 18 November 2013 02:18 PM, Hans Feldt wrote:
> I don't think you have even read what I wrote below...
[Surya] Well, your guess is wrong, but that does not hurt. My
question(response) is still valid.
>>As I said this problem originates from a low memory condition on the payload
>>that
Just to sort out node fencing and recap the architecture we have I checked old
and new code.
In 3.x, avd upon detecting heartbeat loss, would inform avm about this. avm
would inform fm. fm would I guess issue HPI reboot of the node. When the reboot
response is received, only then would avd fail
The original problem described in #600, the payload fails to go down when it
looses
contact with all SCs, sounds like it should be possible to catch. Best would be
if the
AMFND somehow caught it. So the AMFND should perhaps set redundant subscription
of AMFD
(or was it non redundant I always fo
Upgrade a component in this way can only be done if the component is
"restartable".
That's the only case where you can change component type and then initiate the
"restart"
admin operation on the component. Do we think we'll support such an upgrade for
immnd
(or any other central OpenSAF compon
I don't think you have even read what I wrote below...
> -Original Message-
> From: SuryaNarayana Garlapati [mailto:suryanarayana.garlap...@oracle.com]
> Sent: den 18 november 2013 09:41
> To: Nagendra Kumar; Hans Feldt; Hans Nordebäck; Praveen Malviya; Mathivanan
> Naickan Palanivelu
> C
one basic question:
If the bearer is dual, tipc flickering on one link should be transparent
and there will be no effect to applications as the other bearer is
still alive and healthy.
If still the TIPC DOWN's are delivered to the applications, then this is
purely a protocol problem in TIPC.
I
I dont understand the question below.
What "upgrade" of the immnd process are we talking about ?
/AndersBj
-Original Message-
From: Nagendra Kumar [mailto:nagendr...@oracle.com]
Sent: den 18 november 2013 05:50
To: Hans Feldt; Hans Nordebäck; Anders Björnerstedt
Cc: opensaf-devel@lists.s
>> Does amfd try to fence the payload when this happens?
Amfd reset Amfnd information, but Amfnd lives like an orphan as Amfd will not
entertain any requests from Amfnd.
Thanks
-Nagu
-Original Message-
From: Hans Feldt [mailto:hans.fe...@ericsson.com]
Sent: 18 November 2013 12:56
To: Na
26 matches
Mail list logo
