osaf/services/saf/amf/amfd/si.cc | 5 +
1 files changed, 5 insertions(+), 0 deletions(-)
Problem: A SI is unlocked and it is not assigned to any SU. User
does not have any clue for unassignment.
Reason: Reasons for unassignment can be many.Since admin operation
is invoked on the SI and a S
osaf/services/saf/amf/amfd/si.cc | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
Problem: A SI is unlocked and it is not assigned to any SU. User
does not have any clue for the outcome of admin operation.
Reason: Reasons for unassignment can be many, AMF should log
that SI is not ass
Since there can be many more reasons why the SI is not assigned, I don't think
you should log any of what you have proposed in this part of the code. SG, SU
can be locked. Node can be locked etc.
In other places in the code we could log more when we actually know more things.
/Hans
> -Orig
On 07-May-14 11:05 AM, Hans Feldt wrote:
> Since there can be many more reasons why the SI is not assigned, I don't
> think you should log any of what you have proposed in this part of the code.
> SG, SU can be locked. Node can be locked etc.
This is admin operation on SI. This is the reason why
All I am saying that I think you should just log "SI '%s' could not be
assigned to any SU".
The reasons for this has to be logged/found somewhere else.
Thanks,
Hans
On 7 May 2014 07:59, praveen malviya wrote:
>
> On 07-May-14 11:05 AM, Hans Feldt wrote:
>> Since there can be many more reasons why
Ack, minor comment you could change "is not" => "could not be"
Thanks,
Hans
> -Original Message-
> From: praveen.malv...@oracle.com [mailto:praveen.malv...@oracle.com]
> Sent: den 7 maj 2014 10:37
> To: Hans Feldt; nagendr...@oracle.com
> Cc: opensaf-devel@lists.sourceforge.net
> Subject:
