03:02:26 <Sundar> #startmeeting openstack-cyborg
03:02:27 <openstack> Meeting started Thu Oct 24 03:02:26 2019 UTC and is due to finish in 60 minutes.  The chair is Sundar. Information about MeetBot at http://wiki.debian.org/MeetBot.
03:02:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:02:30 <openstack> The meeting name has been set to 'openstack_cyborg'
03:02:43 <Sundar> #topic Who's here
03:02:46 <Sundar> o/
03:02:48 <shaohe_feng> seems you did not finish last meeting
03:02:54 <s_shogo> Hi all
03:02:58 <s_shogo> #info s_shogo
03:03:02 <shaohe_feng> o/
03:03:02 <chenke> #info chenke
03:03:05 <chenke> 0/
03:03:12 <chenke> hi all~
03:03:14 <shaohe_feng> #info shaohe_feng
03:03:19 <Yumeng> #info Yumeng
03:03:24 <Sundar> Hi y'all
03:03:30 <Sundar> #topic Agenda
03:03:40 <Sundar> https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda
03:03:42 <shaohe_feng> what does y' means?
03:03:57 <Sundar> :)  "you all"
03:04:22 <Sundar> Anything to add to the agenda?
03:04:30 <xinranwang> hi all
03:04:37 <Sundar> Hey xinranwang
03:04:49 <Sundar> #topic Summit and PTG
03:05:26 <Sundar> First, re. project update at the summit, I got clarification after the last meeting.
03:05:39 <shaohe_feng> will miss the Team dinner :')
03:05:41 <Sundar> It is actually on. But it is not recorded as video.
03:06:27 <Sundar> Sorry to have mis-stated before I got the clarification. Yumeng, I will create the slides and we can work on them.
03:07:01 <Sundar> shaohe_feng: we will get you a good dinner in Beijing ;)
03:07:33 <shaohe_feng> Thanks
03:07:48 <shaohe_feng> you will visit Beijing?
03:07:58 <shaohe_feng> after PTG
03:08:05 <Sundar> PTG: #link http://ptg.openstack.org/
03:08:18 <Yumeng> Sundar: ok.
03:08:26 <Sundar> All the info for PTG is here.
03:08:45 <Sundar> It turns out that nearly all projects get only a table, not a separate room.
03:09:21 <Sundar> http://ptg.openstack.org/ptg.html Diable is a table, not a room
03:09:25 <Sundar> *Diablo
03:09:48 <Sundar> Not sure how well that works, but that's the case for most projects
03:11:35 <Sundar> Etherpad: The current etherpad (https://etherpad.openstack.org/p/cyborg-ptg-ussuri) will need to be merged into the final one: https://etherpad.openstack.org/p/shanghai-ptg-cyborg
03:11:49 <chenke> We have three days
03:11:49 <Sundar> I will take care of it, once we have enough content in the current etherpad
03:12:14 <Sundar> chenke: True -- but that is a misleading because Wednesday includes the summit too
03:12:36 <chenke> Yes.
03:12:48 <Sundar> I have activities on Wednesday, such as office hours for Cyborg
03:13:23 <Sundar> Also, the project onboarding is part of the PTG this time. So, we will be spending some time talking to newcomers who want to contribute to Cyborg
03:13:42 <Sundar> I suspect it will really be 2 days of discussion
03:14:44 <chenke> It seems that time is sufficient.
03:14:54 <Sundar> Finally: the team photo shoot is part of the PTG: on Thu at 2 pm (after lunch). But that is only 10-15 min
03:15:19 <Sundar> Does anybody have any questions or comments on the PG or the summit?
03:15:21 <Sundar> *PTG
03:17:35 <Sundar> OK, moving on
03:17:43 <Sundar> #topic Doc patches
03:18:24 <Sundar> The documentation has merged into stable/train -- yay! Thanks, xinranwang, Yumeng, chenke and all for proposing/reviewing it.
03:18:43 <chenke> Great.
03:19:00 <Sundar> Now Train has truly left the station for Cyborg. ;)
03:20:02 <Sundar> I see soem new patches from Yumeng and others for docs. Yumeng, you don't expect this to be backported to Train, right?
03:21:27 <Yumeng> sundar: no, no need to backported to Train. what do you think?
03:21:32 <Sundar> We need to check how this differs from other API doc that got merged
03:21:42 <Yumeng> https://review.opendev.org/#/c/690539/
03:22:35 <Sundar> Your patch has more detail.
03:23:51 <Sundar> OK, anything else on docs? We need similar content for ARQs, etc., I suppose.
03:23:56 <Yumeng> I took keystone api-ref as a reference, they have deprecated and current  APIs
03:24:27 <Yumeng> here is the keystone api-ref: https://docs.openstack.org/api-ref/identity/
03:24:31 <Yumeng> take a look
03:24:38 <Sundar> Cool.
03:24:54 <Sundar> #topic Other patches
03:25:19 <Sundar> https://review.opendev.org/#/c/685542/
03:25:58 <Sundar> My question is, should we expend more effort on the ksa_adapter and older methods, or should we aim to move to openstacksdk?
03:27:09 <chenke> According to eric's advice. He suggest we use openstacksdk.
03:28:33 <Sundar> So, what should be the status of this patch?
03:28:50 <chenke> It is easier to use than before.
03:29:23 <chenke> If your devstack env test ok.
03:29:47 <chenke> I suggest to merge this patch and this https://review.opendev.org/#/c/690509/2.
03:30:19 <Sundar> Ok, I'll try it out. The 2nd one is definitely an improvement
03:30:31 <xinranwang> Please review this patch too, after async bind merged, GPU is not supportted. https://review.opendev.org/#/c/688239/
03:30:37 <chenke> Ye.
03:30:49 <chenke> Sundar: Thanks.
03:31:20 <xinranwang> And there is a bug in placement client, please review this one too :) https://review.opendev.org/#/c/688231/
03:31:31 <Yumeng> Sundar: I think we can merge patch 685542, no more effort on ksa_adapter and  openstacksdk for now.
03:32:36 <Sundar> xinranwang, Yumeng: yes to both
03:33:31 <Sundar> Any other patches to be highlighted today? I know there are a bunch of others that need review.
03:35:04 <Sundar> #topic AoB
03:35:21 <Sundar> If there is nothing else, we can get back 25 minutes.
03:36:11 <shaohe_feng> Will we support Orchestrator components(or system IAAS sotrware tools)  also want to leverage accelerators?
03:36:25 <shaohe_feng> These components may run on the same host node with VM guest.
03:36:39 <shaohe_feng> Seems this is out of cyborg control. (should we add a reservation mechanism for them?)
03:36:44 <Sundar> Could you elaborate or provide links?
03:37:11 <shaohe_feng> I have attend a meeting about accelerators.
03:38:12 <shaohe_feng> Get the information, not only VM need accelerator, but maybe some other applications run on the host node also need accelerators
03:39:02 <Sundar> It is not common in an OpenStack cluster to have VMs and non-VM processes running on the same compute node.
03:39:51 <shaohe_feng> I meam the  non-VM processes are openstack required components
03:40:03 <shaohe_feng> Not sure you know RDT.
03:40:24 <Sundar> Yes, I know RDT. Are you referring to RMD?
03:40:34 <shaohe_feng> No
03:40:37 <shaohe_feng> RDT
03:40:53 <shaohe_feng> the use case is:
03:41:04 <shaohe_feng> Divide cache into 2 parts.
03:41:29 <Sundar> Resource Director technology (RDT) is a set of Intel processor features for cache/memory management. They can be used in OpenStack in different ways.
03:41:42 <shaohe_feng> 1 parts are reserved for system IAAS sotrware run on the node
03:42:04 <shaohe_feng> another parts are reserved for VM.
03:42:49 <Sundar> That part is outside Cyborg though -- it relates to cache/memory and should be configured by the operator. How does it relate to accelerators?
03:43:17 <shaohe_feng> We defined, cyborg can only allocate accelerators to nova, right?
03:43:48 <shaohe_feng> I means like RDT.
03:43:58 <shaohe_feng> we have 5 accelerators.
03:44:11 <shaohe_feng> we divided into 2 parts.
03:45:20 <shaohe_feng> 1 parts have 1 acc, it is out of cyborg control.  It is reserved for system IAAS sotrware. Admin allocate them
03:45:56 <shaohe_feng> another parts have the remain 4 acc, cyborg allocate them to nova.
03:46:09 <shaohe_feng> similar like RDT use case.
03:46:38 <shaohe_feng> on we can simple define cyborg.
03:47:20 <shaohe_feng> if cyborg run on a host node. we not allow to allocate accelerators to system IAAS sotrware any more.
03:47:38 <shaohe_feng> we can note this on cyborg docs.
03:47:44 <Sundar> If the admin wants to keep aside some accelerators, he/she can update Placement to mark that resource provider as in-use.
03:48:22 <Sundar> From Cyborg's POV it created the RP but Placement will never pick that RP because it sees it as in-use
03:49:26 <xinranwang> As we know, cinder has enable qat driver, I guess shaohe want to know if Cyborg can help cinder manage this kind of accelerator, is that what you want say, shaohe_feng?
03:49:44 <shaohe_feng> not only cinder
03:49:53 <shaohe_feng> also for some VPN on the host.
03:50:02 <chenke> what does POV means?
03:50:02 <shaohe_feng> and storage
03:50:08 <xinranwang> yes, cinder is just an example
03:50:12 <Sundar> chenke: point of view
03:50:17 <shaohe_feng> DPDK, SPDK also need .
03:50:25 <shaohe_feng> yes, it is an example
03:50:49 <shaohe_feng> so does that means, let cyborg run first before other system IAAS sotrware,  it report resources to placement first
03:51:34 <shaohe_feng> and amdin reserve some accelerators, and start the remain system IAAS sotrwares
03:52:11 <shaohe_feng> and amdin reserve some accelerators to the remain system IAAS sotrwares
03:52:57 <Sundar> Not sure where this discussion is headed. If Cinder is using a device, operator should not configure Cyborg driver for that device. If the admin wants to dedicate some networking/storage devices for DPDK/SPDK and they were claimed by Cyborg, the admin could still mark them in placement, as I said.
03:53:01 <shaohe_feng> We can add this usage as a guideline in cyborg doc.
03:54:04 <shaohe_feng> Sundar: can we add this to the cyborg doc?
03:54:17 <Sundar> shaohe_feng: It may be better to wait for concrete usage by operators and get their feedback, instead of adding hypothetical use cases in the docs -- they could be confusing.
03:54:19 <shaohe_feng> maybe DPDK as example.
03:55:10 <s_shogo> I also interested in disabling to allocate some accelerators, as maintenance.
03:55:43 <Sundar> s_shogo: Only when no VM is using that device, right?
03:55:56 <s_shogo> Sundar: yes
03:56:00 <shaohe_feng> Maybe we had better not allow DPDK to use accelerators any more. This can make things more simple.
03:56:09 <xinranwang> Currently, operator plays this role.
03:57:18 <shaohe_feng> For example, had better to avoid DPDK  to use some network accelerator.
03:57:50 <shaohe_feng> Then things is simple.
03:57:53 <Sundar> s_shogo: Would the admin-Placement method work for now? We had plans to add health reporting and enabling/disabling devices. Once we have the /v2/devices API, we could add this functionality. Seems ok?
03:58:46 <Sundar> shaohe_feng: Cyborg does not support network resources today.
03:59:02 <shaohe_feng> yes, just a example.
03:59:35 <shaohe_feng> QAT can be used for some network accelerations
03:59:47 <shaohe_feng> and it can be used by DPDK.
04:00:00 <shaohe_feng> not sure  cyborg will support QAT
04:00:23 <s_shogo> Sundar: Yes, the approach is good. I want to discuss the methods continuously with example usecase for maintenance and that's requirements.
04:00:26 <shaohe_feng> Or cyborg just plan to manager only VM used accelerators.
04:01:37 <Sundar> shaohe_feng: Do you have specific knowledge that somebody wants to have several QATs in one host, some for VMs, and some for DPDK on the host?
04:02:45 <Sundar> s_shogo: Sure, let's make this a discussion topic at the PTG. Your I could create an etherpad with the problem statement and some ideas.
04:03:15 <Sundar> *You or I
04:04:25 <shaohe_feng> usually，they use kolla to deploy the system IAAS sotrwares include (placement), How do kolla know what's accelerators in placement？
04:04:30 <s_shogo> Sundar : Thanks, I'll update the etherpad (part of the topic is already written)
04:05:31 <Sundar> My suggestion: let's get Nova integ done and make something functional. Then we can start talking about more advanced use cases.
04:05:52 <Sundar> We are over the time. Is there anything else?
04:06:49 <shaohe_feng> Yes, the meeting tells use DPDK can use accelerators. But they does not say DPDK can not live with VM on same host.
04:07:10 <shaohe_feng> Ok.
04:07:36 <shaohe_feng> seems, we did not support much advanced use cases at present.
04:07:40 <shaohe_feng> step by step
04:08:10 <Sundar> shaohe_feng: Let's take this offline.
04:08:16 <Sundar> Good. Thanks a lot, everybody. Have a good day!
04:08:20 <Sundar> #endmeeting