03:01:09 <Sundar> #startmeeting openstack-cyborg
03:01:10 <openstack> Meeting started Thu Nov 28 03:01:09 2019 UTC and is due to finish in 60 minutes.  The chair is Sundar. Information about MeetBot at http://wiki.debian.org/MeetBot.
03:01:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:01:13 <openstack> The meeting name has been set to 'openstack_cyborg'
03:01:17 <s_shogo> Hi all
03:01:26 <Sundar> #topic Agenda and status
03:01:38 <Sundar> Agenda: https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda
03:02:12 <Sundar> Hi s_shogo, may be we can wait a couple of min.
03:02:46 <chenke> Hi all
03:02:58 <s_shogo> Hi Sundar , OK,NP
03:03:03 <xinranwang> Hi all
03:03:10 <Coco_gao_> Hi all
03:03:49 <Yumeng> #info Yumeng
03:03:50 <Yumeng> hi all
03:04:07 <chenke> #info chenke
03:04:18 <Sundar> Hi all
03:04:26 <s_shogo> #info s_shogo
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/
03:56:53 <Sundar> Any comments or questions?
03:59:22 <Sundar> #topic AoB
03:59:26 <Coco_gao_> seems like I have a lot to catch up
04:01:02 <Sundar> Coco_gao_: Yes, the pace has picked up. Any of us will be happy to help you catch up.
04:01:33 <Coco_gao_> I will try to review the patches first.
04:02:08 <Sundar> Alright, I'll try to post the agenda for the next call early on. It will include Programming APIs, functional tests and the multi-node env.
04:02:38 <xinranwang> Oh
04:02:55 <xinranwang> Forget to mention
04:03:10 <xinranwang> I am working on microversion
04:03:34 <xinranwang> I find the cyborg does not really support microverison
04:04:25 <xinranwang> just have some definition of min, max version etc.
04:05:01 <Sundar> xinranwang: Yes, but we have the basics for that, right? I mean, /v2 URL returns min, max. We ned to add support for X-OpenStack-API-version. Right?
04:05:06 <xinranwang> I think we should implement microversion and control it  by decorator.
04:05:55 <Sundar> OK. Do you think it requires a spec or etherpad for discussion? Or can be put in a patch directly?
04:06:22 <xinranwang> If you run `openstack versions show`, you will see that cyborg does not really support microversion.
04:06:47 <xinranwang> I think one patch is ok, just want to confirm one thing
04:07:07 <xinranwang> if we add device/deployable APIs, it will be 2.1 microversion, right?
04:07:35 <Sundar> Since these are the very first version, yes, I think it will be 2.1.
04:07:51 <xinranwang> Ok
04:07:59 <Sundar> We should probably add the same for device_profile and ARQ APis too.
04:08:29 <xinranwang> I was thinking that device_profile, arq should be 2.0
04:09:49 <Sundar> I see. then shouldn't /devices be 2.0 too?
04:10:29 <Sundar> We have run over time, sorry about that.
04:10:45 <Sundar> We can resume this next time, xinranwang, if you don;t mind.
04:11:00 <xinranwang> ok
04:11:33 <Sundar> Final point: while we are pushing on Nova integ, we can also deliver value for Cyborg as a stand-alone service: to list/manage accelerators/devices, to update device firmware or program FPGAs offline, etc. So, all the topics I listed for next meeting are important.
04:12:16 <Sundar> Goodbye
04:12:28 <Sundar> #endmeeting