Hi Eric,

Thanks for the detail comments.

In my plan, the return value for get_fault API will be like below:

(False, None): there is error in the API execution.

(True, None): API execution correctly, and there is no alarm message.

(True, Alarm): API execution correctly, and there is alarm message.

I think it should fix the issue you have. Is it right?

If you agree on this new API return value change, I will implement it.

Thanks.

Best Regards

Shuicheng

From: MacDonald, Eric [mailto:Eric.MacDonald@windriver.com]
Sent: Tuesday, February 19, 2019 10:35 PM
To: Lin, Shuicheng <shuicheng.lin@intel.com>; Liu, Tao <Tao.Liu@windriver.com>
Cc: Xie, Cindy <cindy.xie@intel.com>
Subject: RE: Improve FM's Python API return data

I took a look and added comments. I don’t think this update fixes the issue I have.

From: Lin, Shuicheng [mailto:shuicheng.lin@intel.com]
Sent: Monday, February 18, 2019 10:09 PM
To: MacDonald, Eric; Liu, Tao
Cc: Xie, Cindy
Subject: RE: Improve FM's Python API return data
Importance: High

Resend the mail.

Best Regards

Shuicheng

From: Lin, Shuicheng
Sent: Tuesday, February 19, 2019 9:56 AM
To: Liu, Tao (Wind River) <tao.liu@windriver.com>; 'eric.macdonald@windriver.com' <eric.macdonald@windriver.com>
Cc: Xie, Cindy <cindy.xie@intel.com>
Subject: Improve FM's Python API return data

Hi Tao/Eric,

For story 2004859, I plan to modify the get_fault api return value as a tuple.

(True/False, Alarm)

Alarm is valid only when the 1^st item is True.

Sample code is uploaded for you early review:

Stx-fault: https://review.openstack.org/637655

Stx-integ: https://review.openstack.org/637656

Could you help review it and share your thought?

If you agree on it, I will implement the code and test it.

For test, I will try to kill fmManager/modify its listening port to simulate the failure case.

For the api call outside of stx-fault, I may try to call it manually to verify.

Please share me if there is better verify method.

Thanks.

Best Regards

Shuicheng