| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2019-11-28 | |||
| 03:04:42 | xinranwang | #info xinranwang | |
| 03:04:46 | Sundar | Looks like we got a quorum. Agenda: https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda | |
| 03:05:05 | Sundar | Anything to add? | |
| 03:05:29 | Coco_gao_ | #info Coco_gao | |
| 03:05:42 | shaohe_feng | #info shaohe_feng | |
| 03:05:53 | shaohe_feng | morning Coco_gao | |
| 03:06:07 | shaohe_feng | evening Sundar | |
| 03:06:20 | xinranwang | Sundar: no from me, please go ahead | |
| 03:06:29 | Sundar | #topic v1 API | |
| 03:06:42 | Sundar | Interesting discussion in https://review.opendev.org/#/c/690539/ | |
| 03:07:47 | Sundar | I was thinking that we deprecated v1 API in Train and so we can remove it in Ussuri. There could be other opinions. Should we keep it or drop it? | |
| 03:10:22 | Sundar | Yumeng, chenke, xinranwang, s_shogo, shaohe_feng Coco_gao_: ^ | |
| 03:11:57 | shaohe_feng | How many users are using V1? | |
| 03:12:01 | Coco_gao_ | According to Openstack rules, it's OK to deprecate v1 API in Ussuri, right? | |
| 03:12:21 | Sundar | Probably nobody in production. Maybe a few users like s_shogo could be using it in a lab? | |
| 03:12:58 | s_shogo | I'm using v2 API. v2 API covers v1's role, removing is OK, IMO. | |
| 03:13:00 | Sundar | Coco_gao_: we already deprecated it in Train. Are you asking can we leave it in deprecated state in Ussuri? | |
| 03:13:10 | Li_Liu | #info Li_Liu | |
| 03:13:24 | xinranwang | The v1 definition of deployable and accelerator may confused people who wanna look into cyborg, | |
| 03:13:44 | Sundar | xinranwang: good point, agree | |
| 03:13:49 | s_shogo | xinranwang +1 | |
| 03:13:55 | xinranwang | I have got such kind of confusion from others. | |
| 03:15:24 | Coco_gao_ | V1 and V2 are so different. I prefer to remove v1 in Ussuri. | |
| 03:16:03 | Sundar | Anybody against removing v1 API in Ussuri? | |
| 03:16:28 | chenke | remove +1. | |
| 03:17:18 | xinranwang | Cause v2 API is not complete yet, we should at least let other know that there is no need to look into V1 and get a wrong picture. | |
| 03:17:27 | Sundar | Yumeng: since you had a different opinion, please let me know if we have missed some point or alternative view to consider. | |
| 03:17:37 | Yumeng | ok. we don't want cause confusions. Since that, I can remove api-ref v1 and not keep it as deprecated status. and move deployable to v2 | |
| 03:18:04 | Coco_gao_ | Let's focus on V2 | |
| 03:18:08 | Sundar | Good, it is also less work, because we don't need to document v1 API. | |
| 03:18:22 | Sundar | #agreed Remove v1 API in Usuri. | |
| 03:18:26 | Yumeng | move deployable to v2 and delete v1 accelerator | |
| 03:18:27 | s_shogo | I'll modify the python-client, to remove the v1 implementation. (correspondly to the controller patch) | |
| 03:18:45 | Sundar | Thanks, s_shogo and all | |
| 03:18:49 | Sundar | #topic Programming API proposal review | |
| 03:19:05 | Sundar | #link https://etherpad.openstack.org/p/cyborg-ussuri-programming-apis | |
| 03:19:14 | Sundar | Did anybody have a chance to review this? | |
| 03:20:24 | Sundar | If not, we can schedule it for next week. | |
| 03:21:24 | xinranwang | Ok | |
| 03:21:30 | Sundar | I suspect people are reading it now. :) | |
| 03:21:37 | Coco_gao_ | reading now | |
| 03:22:06 | Sundar | Cool, Please comment in the etherpad and we can revisit next week. | |
| 03:22:20 | Sundar | #topic Functional tests update | |
| 03:22:24 | xinranwang | As the programming API (device layer) will be seperated from other general device API, i will remove firmware upgrade part from my device API spec . | |
| 03:22:57 | Li_Liu | I took a quick look on the functional test part | |
| 03:23:33 | Li_Liu | I am drafting a test plan for that | |
| 03:23:57 | Sundar | Li_Liu: Great. Good to know that. Will that be in an etherpad? | |
| 03:24:28 | Sundar | xinranwang: Ok | |
| 03:25:11 | Li_Liu | I will put it on etherpad | |
| 03:26:08 | Sundar | Thanks, Li_Liu | |
| 03:26:23 | Sundar | #topic Storyboard review and update | |
| 03:26:44 | Li_Liu | np | |
| 03:26:45 | Sundar | #link https://storyboard.openstack.org/#!/project/openstack/cyborg | |
| 03:27:47 | Sundar | I put in the major Ussuri goals from the PTG, and cleaned up some of the old ones. Please feel free to add or update the entries. | |
| 03:28:06 | Sundar | But, if you want to delete something, please check with the group first. | |
| 03:28:54 | Sundar | Many of them are still open. | |
| 03:30:00 | Sundar | Please take a look and update the ones with your name as you go along. | |
| 03:30:41 | Sundar | #topic Status of patches | |
| 03:31:56 | Coco_gao_ | Have someone taken some of the tasks? | |
| 03:31:57 | s_shogo | python-client :v2/sdk patches are still under review, pls review this :) https://review.opendev.org/#/c/681391/ ) | |
| 03:32:00 | Sundar | shaohe_feng: Do you want to update us on multi-host devstack setup? Or do you need input from us on the config table? | |
| 03:32:53 | shaohe_feng | I will update a new patch for program as you comments in the patch | |
| 03:33:13 | Sundar | Some tasks have assignees. if a task has no owner assigned to it, it is open. | |
| 03:33:32 | shaohe_feng | for the storyboard just list 2 issues. | |
| 03:33:49 | Sundar | shaoehe_feng: You mean a patch to improve the fake driver for programming? | |
| 03:34:00 | shaohe_feng | yes. | |
| 03:34:12 | shaohe_feng | the patch just cover the storyborad. | |
| 03:34:30 | shaohe_feng | we should not mix many issues in one patches. | |
| 03:35:06 | Sundar | OK. If you want to spli them into different patches, that's fine. May be one for the conf settings, one for fake driver? | |
| 03:36:00 | Yumeng | Coco_gao_: some are taken, there are still tasks left not taken by people. --.-- | |
| 03:36:00 | shaohe_feng | one for the current storyboard | |
| 03:36:23 | shaohe_feng | another for the left maybe. | |
| 03:36:30 | Li_Liu | Sundar, regarding this one https://review.opendev.org/#/c/696014/ | |
| 03:36:44 | Li_Liu | do you want me to add UT in the same patch or a different one? | |
| 03:38:26 | Sundar | shaohe_feng: You can expand https://storyboard.openstack.org/#!/story/2006618 into different tasks and do them one at a time, if that's what you mean. | |
| 03:39:59 | shaohe_feng | OK，let me think it over | |
| 03:40:03 | Sundar | Li_Liu: I'll leave the decision to you. Generally, folks from other projects notice the lack of UT in our patches, so it may be better to add something here. But, if you feel that there is a lot to do, you could make that into a patch series. | |
| 03:40:53 | Sundar | All, here's a good doc for developing in a patch series: https://docs.openstack.org/contributors/code-and-documentation/patch-series-tutorial.html | |
| 03:41:02 | Li_Liu | i see. I will add the ut in the same patch then | |
| 03:41:13 | Li_Liu | cool | |
| 03:42:26 | Coco_gao_ | Good tutorial for me, aha~ | |
| 03:42:44 | Sundar | s_shogo: Thanks for the client patch :) | |
| 03:43:18 | Sundar | I'll try to get some openstacksdk folks to review this. | |
| 03:43:29 | s_shogo | Sundar sorry for interruption.. and thanks to pick up | |
| 03:44:29 | Sundar | Does anybody want to discuss any specific patch? | |
| 03:45:33 | Sundar | #topic Nova status | |
| 03:46:06 | Sundar | I'll try to give updates on the Nova side as we go along. If most of you think it is not productive, please LMK. | |
| 03:46:47 | Sundar | The pace of review is picking up again, as we get sustained attention from nova cores now. The discussions we had in PTG seem to be paying off. | |
| 03:47:03 | Li_Liu | Sounds great | |
| 03:48:12 | Sundar | The biggest change in the last week is that we are doing a partial U-turn :) A long time ago, around March 2019, we used to create and kick off the ARQ binding in the Nova conductor, and poll for the completion in Nova virt driver (part of the Nova compute manager). | |
| 03:48:44 | Sundar | In the Train PTG, it was decided that Cyborg should notify Nova, not have Nova poll Cyborg. | |
| 03:49:51 | Sundar | But, if we start the binding first and then wait for the notification, the notification event gets lost, because Cyborg responds quickly. | |
| 03:50:59 | Sundar | SO I changed it to start the wait and then call Cyborg to kick off the binding -- no event loss, but this means the binding is started in Nova compute manager in the compute node, not the controller. | |
| 03:51:16 | Sundar | This is what we had in Train. The spec was updated and approved to reflect that. | |
| 03:51:37 | Sundar | Any questions so far? | |
| 03:52:07 | shaohe_feng | something wrong with my IRC network. | |
| 03:53:44 | Sundar | Ok. The latest discussion observes that we lose some concurrency by starting the bind so late. So, we are moving the start of the binding back to the conductor, But a new patch has been proposed in Nova to address he potential loss fof the event: https://review.opendev.org/#/c/695985/ | |
| 03:54:46 | Sundar | This means I can start the wait in compute manager, call Cyborg once to check if the binding is done and, if it is done, quit he wait. | |
| 03:55:38 | Sundar | I am still trying out this change. There are tons of other changes suggested, and I am working on them too. | |
| 03:56:36 | Sundar | Other patches have also been proposed in Nova to help CYborg-Nova integ: https://review.opendev.org/#/c/696380/ | |