| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2019-10-24 | |||
| 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 | |