| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-06-06 | |||
| 14:44:40 | zhipeng | okey let's go to Sundar's four spec | |
| 14:44:53 | zhipeng | Sundar which one do you think is ready to go ? | |
| 14:45:03 | Sundar | All of them :) | |
| 14:45:17 | zhipeng | haha great | |
| 14:45:20 | Sundar | I will still request Nova folks to do a +1 on scheduling spec. | |
| 14:45:37 | zhipeng | yes that one has gone through a lot | |
| 14:45:48 | Sundar | For os-acc also, we should probably get Nova ok, right? | |
| 14:46:42 | shaohe_feng | os-acc will call cyborg-agent? | |
| 14:46:55 | zhipeng | https://review.openstack.org/#/c/566798/ | |
| 14:46:55 | shaohe_feng | and nova will call os-acc？ | |
| 14:46:59 | zhipeng | this one right ? | |
| 14:47:23 | Sundar | zhipeng, yes | |
| 14:47:25 | zhipeng | shaohe_feng I think nova-compute calls os-acc to do the attach/detach | |
| 14:47:58 | zhipeng | but I think the original goal of os-acc is to serve as a library | |
| 14:48:06 | Sundar | shaohe: Yes, as zhipeng says. | |
| 14:48:31 | zhipeng | Sundar does nova-compute also calls os-brick or os-vif ? | |
| 14:48:32 | Sundar | zhipeng, yes. It is still a library that Cyborg provides, like os-vif for Neutron | |
| 14:49:20 | Sundar | zhipeng, yes, nova compute calls into os-vif -- plug(), unplug() API | |
| 14:49:25 | Sundar | I'll try to get a link | |
| 14:49:37 | shaohe_feng | zhipeng, so that means nova will call agent by attach/detach directly? | |
| 14:50:05 | shaohe_feng | is there no race for cyborg API and os-acc? | |
| 14:50:29 | zhipeng | i think for the nova scenario, which means accelerator attachment for the VM | |
| 14:50:52 | zhipeng | the attach should be issued by nova-compute | |
| 14:50:58 | zhipeng | however for the baremetal usecase | |
| 14:51:07 | zhipeng | it should be gone through cyborg-api | |
| 14:51:08 | shaohe_feng | Sundar, os-vif plug API call nuetron agent? | |
| 14:51:50 | zhipeng | i think we should target os-acc for VM usecase for Rocky | |
| 14:52:12 | zhipeng | which means os-acc alls the cyborg-agent directly to call upon the driver | |
| 14:52:26 | Sundar | That is my understanding. We can double check. But, please note that the spec doesn't make implementation commitments yet. We can implement it the same way as os-vif | |
| 14:52:28 | zhipeng | (and the driver invoke the bus protocols) | |
| 14:52:54 | Sundar | zhipeng: Agreed :) | |
| 14:52:56 | shaohe_feng | edleafe, os-vif can call neutron agent directly by RPC by-pass API? | |
| 14:53:00 | Sundar | shaohe: I think you may be referring to scenarios like the one where Cyborg API is called to program a region, which is already in use? | |
| 14:53:42 | zhipeng | i think the attach/detach does not make assumption on the operation | |
| 14:53:47 | wangzhh | Hi， I'm confused. Could anyone explain. When nova-compute call cyborg by os-acc, It will call by http(API) or just by rpc(message queen)? | |
| 14:53:50 | zhipeng | no matter a region needs to be programmed or not | |
| 14:54:02 | zhipeng | if attach, it presumes the device is ready | |
| 14:54:33 | wangzhh | Or both of them? | |
| 14:54:35 | zhipeng | wangzhh the current thinking is via rpc to call cyborg-agent in order to get to the driver | |
| 14:54:47 | zhipeng | no api involved in this scenario | |
| 14:55:21 | wangzhh | OK. Thx. | |
| 14:55:29 | Sundar | Yes, agreed with zhipeng | |
| 14:55:48 | Sundar | Here are the interfaces exposed by os-vif: https://github.com/openstack/os-vif/blob/master/os_vif/__init__.py | |
| 14:56:04 | Sundar | I will try to locate how nova compute calls it | |
| 14:56:04 | zhipeng | it means that this is a VM related operation and we assume the Nova got the necessary previllage | |
| 14:56:30 | zhipeng | we could focus on the details later, whether the lib itself could be called | |
| 14:56:45 | zhipeng | or something implement the lib interfaces should be called | |
| 14:57:35 | Sundar | Nova compute calls the initialize API of os-vif directly here: https://github.com/openstack/nova/blob/master/nova/cmd/compute.py#L49 | |
| 14:57:35 | zhipeng | okey so everyone good on the os-acc spec ? | |
| 14:59:05 | shaohe_feng | what does os_vif.initialize do? | |
| 14:59:27 | shaohe_feng | will it set up RPC client? | |
| 14:59:39 | Sundar | It sets up os_vif for further calls, like plug and unplug to attach/detach network ports to instances | |
| 15:00:06 | shaohe_feng | we want to know the plug detail | |
| 15:00:17 | shaohe_feng | how does it call neutron. | |
| 15:00:37 | shaohe_feng | by API or RPC? | |
| 15:00:51 | Sundar | shaohe: It seems to a direct call AFAICS> Here's the implementation: https://github.com/openstack/os-vif/blob/master/os_vif/__init__.py#L24 | |
| 15:01:51 | Sundar | shaohe: Could I ask whether it is important to settle this now before approving the spec? | |
| 15:02:18 | zhipeng | we could discuss this more in detail for implementation | |
| 15:02:27 | Sundar | The spec focuses on 2 things: behavior of accelerators during start/top/etc. and the os-acc interfaces | |
| 15:02:48 | shaohe_feng | Sundar, it should block the spec. | |
| 15:02:55 | Sundar | The implementation is up to us. There will be more comments on the code patch that implements this :) | |
| 15:03:10 | shaohe_feng | for if it can agent, we should be careful. | |
| 15:04:11 | shaohe_feng | s/for if it can agent/for if it call agent | |
| 15:04:13 | zhipeng | Sundar regarding nrp | |
| 15:04:21 | Sundar | We should be careful in the implementation. But the spec does not say RPC, API or whatever | |
| 15:04:26 | zhipeng | I think from the maillinglist discussion | |
| 15:04:31 | zhipeng | we should still go for it | |
| 15:04:38 | zhipeng | per your sched spec | |
| 15:05:02 | Sundar | Shaohe, if we don;t close on os-acc spec now, what is your proposed plan for Rocky? | |
| 15:06:04 | zhipeng | Sundar shaohe_feng let's moving on from the os-acc specifics | |
| 15:06:19 | shaohe_feng | OK | |
| 15:06:20 | zhipeng | actually let me put down a comment | |
| 15:06:51 | zhipeng | #action os-acc spec https://review.openstack.org/566798 after Li Liu remove -1 is ready to go | |
| 15:07:06 | zhipeng | so Li Liu still has to check :) | |
| 15:07:12 | Sundar | Thanks, zhipeng :) | |
| 15:07:21 | zhipeng | now back on the sched spec | |
| 15:07:31 | zhipeng | nrp | |
| 15:07:38 | zhipeng | I think we should still go for it | |
| 15:07:39 | Sundar | zhipeng, re. nRP, it may still take more time | |
| 15:07:50 | Sundar | We may not deliver anything if we keep waiting for it | |
| 15:08:13 | Sundar | Can we start by applying the traots on compute node RP and moving later when ever nRP is ready? | |
| 15:08:18 | Sundar | *traits | |
| 15:08:23 | zhipeng | given the impression from the Nova team | |
| 15:08:52 | zhipeng | nrp should be a worthy goal for Rocky, if we wait that's gonna be another cycle | |
| 15:09:12 | zhipeng | plus we have Alex here :P | |
| 15:09:45 | Sundar | What will be delivered in Rocky then? | |
| 15:10:17 | zhipeng | all the nrp based traits and rcs we discussed | |
| 15:10:28 | zhipeng | and placement will be ready i suspect | |
| 15:11:46 | shaohe_feng | Sundar, we have a discuss nRP on Monday's meeting. can you summary it? | |
| 15:14:20 | zhipeng | Sundar are you still around ? | |
| 15:14:22 | Sundar | shaohe: after Monday's meeting, I started a thread with Nova. Please see some of the responses, like: http://lists.openstack.org/pipermail/openstack-dev/2018-June/131157.html | |
| 15:14:35 | zhipeng | the agent-driver api spec | |
| 15:14:52 | zhipeng | is this urgent for rocky as well ? | |
| 15:14:58 | Sundar | The virt-drivers need to be updated for nRP, and there are still some concerns around in-place upgrades with nRP | |
| 15:15:40 | Sundar | zhipenf, Just trying to understand :) -- if nRP is not ready in Rocky, what will Cyborg deliver in Rocky? | |
| 15:15:45 | Sundar | *zhipeng | |
| 15:16:37 | zhipeng | Sundar we could make a hack work | |
| 15:16:49 | shaohe_feng | zhipeng, we should make a decision on how we report the resource to placement. | |
| 15:17:14 | zhipeng | shaohe_feng specifically ? | |
| 15:18:36 | zhipeng | Sundar I see the feedbacks in the email thread, and the general feedback is that most of the stuff could be done | |