[Starlingx-discuss] Improve FM's Python API return data

Tue Feb 26 14:18:50 UTC 2019

Agreed.

From: Wensley, Barton
Sent: Tuesday, February 26, 2019 9:11 AM
To: Lin, Shuicheng; MacDonald, Eric; Liu, Tao; Bailey, Henry Albert (Al)
Cc: Xie, Cindy; starlingx-discuss at lists.starlingx.io
Subject: RE: Improve FM's Python API return data
Importance: High

Shuicheng,

As per your spreadsheet, there are actually three APIs that currently return ambiguous results (get_fault, get_faults and get_faults_by_id). My view is that you should be updating all six APIs to be consistent and raise an exception if the operation fails (e.g. because the API can't connect to fmmanager).

You can avoid impacting the existing APIs by having both a FaultAPIs class and a FaultAPIsV2 class. To avoid code duplication, you would create a FaultAPIsBase class to hold all the common code and subclass from it.

Bart

From: Lin, Shuicheng [mailto:shuicheng.lin at intel.com]
Sent: February 25, 2019 8:59 PM
To: MacDonald, Eric; Wensley, Barton; Liu, Tao; Bailey, Henry Albert (Al)
Cc: Xie, Cindy; starlingx-discuss at lists.starlingx.io
Subject: RE: Improve FM's Python API return data

Hi Eric/Tao/Al,
Please confirm you agree a new set fault API (FaultAPIs_V2) or not.
The attached excel is a simple comparison between original class FaultAPIs and FaultAPIs_V2.
For myself, I still prefer to add 2 new API in original class, so other API call could be kept without change.
We could have more discuss about the FaultAPIs_V2 design if you all agree to choose it.

Best Regards
Shuicheng

From: MacDonald, Eric [mailto:Eric.MacDonald at windriver.com]
Sent: Monday, February 25, 2019 10:23 PM
To: Wensley, Barton <Barton.Wensley at windriver.com>; Lin, Shuicheng <shuicheng.lin at intel.com>; Liu, Tao <Tao.Liu at windriver.com>; Bailey, Henry Albert (Al) <Al.Bailey at windriver.com>
Cc: Xie, Cindy <cindy.xie at intel.com>; starlingx-discuss at lists.starlingx.io
Subject: RE: Improve FM's Python API return data

I see your point Bart.
This Jira is an Enhancement Request and fulfilling that should not be done so half way.
All the APIs in V2 should be changed to defer exception handling to the caller as apparently that is the pythonic way.

From: Wensley, Barton
Sent: Monday, February 25, 2019 8:10 AM
To: Lin, Shuicheng; MacDonald, Eric; Liu, Tao; Bailey, Henry Albert (Al)
Cc: Xie, Cindy; starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>
Subject: RE: Improve FM's Python API return data
Importance: High

I disagree with this approach. Instead of just updating two of the methods, you should be updating all the methods in the FaultAPIs class that could fail in the same way and have them raise an exception. You should create a new FaultAPIs_v2 class for the updated methods to avoid impacting existing users. When a user of this API wants to use the new exceptions, they will start using the new class.

Bart

From: Lin, Shuicheng [mailto:shuicheng.lin at intel.com]
Sent: February 25, 2019 2:58 AM
To: MacDonald, Eric; Liu, Tao; Bailey, Henry Albert (Al); Wensley, Barton
Cc: Xie, Cindy; starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>
Subject: RE: Improve FM's Python API return data

Hi all,
Based on the comments in patch [0], I will add two new API, get_fault_ex and get_faults_by_id_ex.
I will not add a new class, since all other APIs are kept without change.
For get_fault_ex and get_faults_by_id_ex:
the return value will be alarm list (maybe None).
Exception will be thrown if there is error during API execution.

[0]: https://review.openstack.org/637655

Best Regards
Shuicheng

From: Lin, Shuicheng [mailto:shuicheng.lin at intel.com]
Sent: Wednesday, February 20, 2019 10:41 AM
To: MacDonald, Eric <Eric.MacDonald at windriver.com<mailto:Eric.MacDonald at windriver.com>>; Liu, Tao <Tao.Liu at windriver.com<mailto:Tao.Liu at windriver.com>>; Al.Bailey at windriver.com<mailto:Al.Bailey at windriver.com>
Cc: Xie, Cindy <cindy.xie at intel.com<mailto:cindy.xie at intel.com>>; starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>
Subject: Re: [Starlingx-discuss] Improve FM's Python API return data

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 at windriver.com]
Sent: Tuesday, February 19, 2019 10:35 PM
To: Lin, Shuicheng <shuicheng.lin at intel.com<mailto:shuicheng.lin at intel.com>>; Liu, Tao <Tao.Liu at windriver.com<mailto:Tao.Liu at windriver.com>>
Cc: Xie, Cindy <cindy.xie at intel.com<mailto:cindy.xie at 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 at 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 at windriver.com<mailto:tao.liu at windriver.com>>; 'eric.macdonald at windriver.com' <eric.macdonald at windriver.com<mailto:eric.macdonald at windriver.com>>
Cc: Xie, Cindy <cindy.xie at intel.com<mailto:cindy.xie at intel.com>>
Subject: Improve FM's Python API return data

Hi Tao/Eric,
For story 2004859<https://storyboard.openstack.org/#!/story/2004859>, I plan to modify the get_fault api return value as a tuple.
(True/False, Alarm)
Alarm is valid only when the 1st 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20190226/910892f1/attachment-0001.html>