[devel] [PATCH 1 of 1] amfnd: Reboot payload when link between Controller and Payload flickers [#600]

osaf/services/saf/amf/amfnd/di.cc | 20 osaf/services/saf/amf/amfnd/evt.cc | 4 +++- osaf/services/saf/amf/amfnd/include/avnd_cb.h | 1 + osaf/services/saf/amf/amfnd/include/avnd_evt.h | 1 + osaf/services/saf/amf/amfnd/mds.cc |

[devel] [PATCH 0 of 1] Review Request for amfnd: Reboot payload when link between Controller and Payload flickers [#600]

Summary: amfnd: Reboot payload when link between Controller and Payload flickers [#600] Review request for Trac Ticket(s): #600 Peer Reviewer(s): hans.fe...@ericsson.com, hans.nordeb...@ericsson.com, mathi.naic...@oracle.com Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE Affected

Re: [devel] [PATCH 1 of 1] amfd: Reject admin op if csi add/remove is in progress [#627]

Hi Hans N, Hans F, Any comments on this ? Thanks -Nagu -Original Message- From: Nagendra Kumar Sent: 14 November 2013 17:11 To: hans.fe...@ericsson.com; hans.nordeb...@ericsson.com Cc: opensaf-devel@lists.sourceforge.net Subject: [devel] [PATCH 1 of 1] amfd: Reject admin op if csi

Re: [devel] [PATCH 1 of 1] amfd: Add support for admin op result strings [#85]

So before there was a mix of saflog and syslog usage. Upfront errors used was logged using syslog and later discovered errors logged using saflog. The OK case went to saflog only. TRYAGAIN errors was logged in syslog. So first we should unify on using saflog for all errors, done. Second

Re: [devel] [PATCH 1 of 1] amfd: Add support for admin op result strings [#85]

Hi Hans, Which basically leaves the logging of error string from my extra patch: What do you think? Fine with me. Thanks -Nagu -Original Message- From: Hans Feldt [mailto:hans.fe...@ericsson.com] Sent: 20 November 2013 15:53 To: Nagendra Kumar; hans.nordeb...@ericsson.com Cc:

Re: [devel] [PATCH 1 of 1] amfd: Add support for admin op result strings [#85]

OK I will push then. /Hans On 11/20/2013 11:38 AM, Nagendra Kumar wrote: Hi Hans, Which basically leaves the logging of error string from my extra patch: What do you think? Fine with me. Thanks -Nagu -Original Message- From: Hans Feldt [mailto:hans.fe...@ericsson.com] Sent:

Re: [devel] [PATCH 1 of 1] amfd: Reject admin op if csi add/remove is in progress [#627]

Hi Nagu, I have problem applying the patch, is it for opensaf-4.3.x branch? Which changeset? /BR HansN -Original Message- From: Nagendra Kumar [mailto:nagendr...@oracle.com] Sent: den 20 november 2013 11:05 To: Hans Feldt; Hans Nordebäck Cc: opensaf-devel@lists.sourceforge.net Subject:

Re: [devel] [PATCH 1 of 1] amfd: Reject admin op if csi add/remove is in progress [#627]

Usually we set the SG state non stable when operating on SUs. So why isn't this standard mechanism used in this case? Thanks, Hans On 11/20/2013 11:05 AM, Nagendra Kumar wrote: Hi Hans N, Hans F, Any comments on this ? Thanks -Nagu -Original Message- From: Nagendra Kumar Sent: 14

Re: [devel] [PATCH 1 of 1] amfd: Reject admin op if csi add/remove is in progress [#627]

Don't remember exactly, but may be because of upgrade issue for adding/deleting csi, extra SG fsm state would have been required, so not coded like typical SG fsm style. Thanks -Nagu -Original Message- From: Hans Feldt [mailto:hans.fe...@ericsson.com] Sent: 20 November 2013 18:33 To:

[devel] [PATCH 1 of 1] IMM: Update the README file to document 2PBE [622]

osaf/services/saf/immsv/README | 167 + 1 files changed, 167 insertions(+), 0 deletions(-) diff --git a/osaf/services/saf/immsv/README b/osaf/services/saf/immsv/README --- a/osaf/services/saf/immsv/README +++ b/osaf/services/saf/immsv/README @@ -1604,6

[devel] [PATCH 0 of 1] Review Request for IMM: Update the README file to document 2PBE [622]

Summary: IMM: Update the README file to document 2PBE (622) Review request for Trac Ticket(s): 622 Peer Reviewer(s): Neel Pull request to: Affected branch(es): default(4.4) Development branch: Impacted area Impact y/n Docs

Re: [devel] [PATCH 1 of 1] amfd: Reject admin op if csi add/remove is in progress [#627]

I think SG FSM state SU OPER should be used for this purpose. Could you please test attached patch? It fits better into the code and no new checks needs to be added into admin op handling Thanks, Hans -Original Message- From: Nagendra Kumar [mailto:nagendr...@oracle.com] Sent: den 20

Re: [devel] [PATCH 1 of 1] IMM: Update the README file to document 2PBE [622]

Hi, Just a thought, I think the README is getting too big and that it could be split it into several files. For example add the new 2PBE stuff into a new file README.2PBE Thanks, Hans -Original Message- From: Anders Bjornerstedt [mailto:anders.bjornerst...@ericsson.com] Sent: den

Re: [devel] [PATCH 1 of 1] IMM: Update the README file to document 2PBE [622]

Ok, will do that. And point to the new file from the basic README. Next up will be the README entry for NO_DANGLING (#50). I may do a separate file for that also, depends on the ammount of text It turns out to be. /AndersBj -Original Message- From: Hans Feldt Sent: den 20 november 2013

Re: [devel] [PATCH 1 of 1] amfd: Reject admin op if csi add/remove is in progress [#627]

And here's a patch that actually works (previous one didn't). Tested with various CSI add/remove for PI/NPI comps. Please test and comment. If avd_sg_su_oper_list_add() instead was called from inside avd_snd_susi_msg() it would save some lines here and there. /Hans -Original Message-

[devel] [PATCH 1 of 1] SMF: Config parameters are read when node director becomes active (#633)

osaf/services/saf/smfsv/smfd/smfd_amf.c | 4 1 files changed, 4 insertions(+), 0 deletions(-) When a parameter in SMF config object is changed only the active node director is updated, the sb-side still hold old values. The config parameters are re-read by the sb node director when

[devel] [PATCH 0 of 1] Review Request for SMF #633

Summary: SMF: Config parameters are read when node director becomes active Review request for Trac Ticket(s): 633 Peer Reviewer(s): Bertil Pull request to: Affected branch(es): default, 4.3.x, 4.2.x Development branch: default Impacted area Impact y/n

Re: [devel] [PATCH 1 of 1] SMF: Config parameters are read when node director becomes active (#633)

Looks OK. /Bertil -Original Message- From: Ingvar Bergström Sent: den 21 november 2013 07:44 To: Bertil Engelholm Cc: opensaf-devel@lists.sourceforge.net Subject: [PATCH 1 of 1] SMF: Config parameters are read when node director becomes active (#633)