| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-08-01 | |||
| 14:11:22 | shaohe_feng | #topic Roll Call | |
| 14:11:32 | shaohe_feng | #info shaohe_feng | |
| 14:11:37 | Li_Liu | #info Li_Liu | |
| 14:11:42 | shaohe_feng | Sundar, morning | |
| 14:11:43 | Helloway_ | #info Helloway | |
| 14:12:25 | Sundar | Hi Shaohe | |
| 14:12:31 | Sundar | #info SUndar | |
| 14:13:30 | shaohe_feng | Li_Liu, what's the agenda of today's meeting? | |
| 14:13:34 | Li_Liu | #topic sub team status | |
| 14:14:06 | Li_Liu | I will go first for documentation team | |
| 14:14:15 | shaohe_feng | good. | |
| 14:14:29 | shaohe_feng | we missing so many docs | |
| 14:14:54 | Li_Liu | We had a kick off meeting earlier today to discuss what need to be done for R | |
| 14:15:21 | Li_Liu | #lind https://etherpad.openstack.org/p/rocky-cyborg-doc | |
| 14:15:25 | Li_Liu | #link https://etherpad.openstack.org/p/rocky-cyborg-doc | |
| 14:15:51 | Li_Liu | the meeting minutes can be found here | |
| 14:16:39 | Li_Liu | in case anyone want to add anything to the documentation list, feel free to edit the etherpad | |
| 14:16:45 | Li_Liu | that's from me | |
| 14:17:10 | shaohe_feng | Sundar, are you here? | |
| 14:17:22 | Li_Liu | shaohe_feng, you wanna do a quick summary on the driver sub team meeting? | |
| 14:17:38 | shaohe_feng | Ok. | |
| 14:17:48 | xinran__ | #info xinran__ | |
| 14:17:51 | xinran__ | Hi all | |
| 14:18:31 | shaohe_feng | xinran__, evening | |
| 14:18:40 | shaohe_feng | dolpher, evening | |
| 14:18:42 | Li_Liu | Hi xinran | |
| 14:18:53 | dolpher | hi | |
| 14:19:00 | shaohe_feng | we should refactor the drivers structure. | |
| 14:19:23 | shaohe_feng | Sundar and Coco will can help with this. | |
| 14:19:33 | Li_Liu | ok | |
| 14:19:34 | Sundar | Shaohe: can you expand on this? ^ | |
| 14:19:46 | shaohe_feng | Sundar, yes. | |
| 14:20:25 | shaohe_feng | Sundar, we had better unify the report info from different drivers | |
| 14:20:57 | Sundar | Do you mean the structures returned by GPU/FPGA drivers etc.? | |
| 14:21:23 | Li_Liu | ... | |
| 14:21:30 | Li_Liu | what was that | |
| 14:21:36 | shaohe_feng | what is sscout15? | |
| 14:22:03 | Li_Liu | I think he's just spamming... | |
| 14:22:30 | xinran__ | ads？ | |
| 14:23:25 | shaohe_feng | Sundar, for FPGA example, we should add function_uuid to the extra attribute | |
| 14:23:25 | Li_Liu | my god... can we ban them? | |
| 14:23:41 | Sundar | There must be some way to configure IRC servers for spam protection? | |
| 14:24:11 | efried | Yes, someone in charge can go to #openstack-infra request that +r be enabled for this channel. | |
| 14:24:27 | efried | That means only registered nicknames will be allowed to join. | |
| 14:24:36 | Li_Liu | ah, ok | |
| 14:24:50 | efried | Note that that's a double-edged sword, so use with caution. | |
| 14:25:06 | efried | I wouldn't think you expect a lot of casual users in this channel. | |
| 14:25:12 | efried | so it's probably appropriate here. | |
| 14:25:13 | Li_Liu | shaohe_feng, are you gonna extend the DB fields? or just use the attribute_list? | |
| 14:25:29 | Li_Liu | efried, sure, will look into it | |
| 14:25:41 | efried | Li_Liu: See http://lists.openstack.org/pipermail/openstack-dev/2018-August/132692.html | |
| 14:25:44 | shaohe_feng | Li_Liu, no we can leverage your attribute tables in DB. | |
| 14:26:02 | shaohe_feng | Sundar, Li_Liu, I add the function_uuid in the attribute. | |
| 14:26:06 | Sundar | Shaohe: we already have function ID: #link https://git.openstack.org/cgit/openstack/cyborg/tree/doc/specs/rocky/cyborg-agent-driver-api.rst?h=refs/changes/49/561849/7#n99 | |
| 14:26:21 | Li_Liu | efried, thanks a lot | |
| 14:26:30 | Sundar | Thanks, efried | |
| 14:26:31 | Li_Liu | shaohe_feng, that's great :) | |
| 14:27:00 | Sundar | Shaohe: are you referring to DB fields? | |
| 14:27:43 | shaohe_feng | So we a user request a accelerator with the function_uuid, cyborg filter the attribute of deployable. | |
| 14:28:08 | shaohe_feng | Sundar, I did it in my poc. | |
| 14:29:06 | shaohe_feng | Sundar, but currently, there is no attribute in the the driver return data info | |
| 14:29:18 | shaohe_feng | so we need to improvement it. | |
| 14:30:50 | shaohe_feng | Li_Liu's attribute DB is important to match our expect accelerators. | |
| 14:31:45 | Sundar | The spec calls for function/region IDs etc. but it has not been implemented yet in the upstream code. You are saying that you have added function ID to the POC. Great. | |
| 14:32:10 | shaohe_feng | Sundar, yes. You can have a loot. | |
| 14:34:02 | shaohe_feng | Sundar, if we use you VAN. | |
| 14:34:37 | shaohe_feng | Have consider how to report traits/resource class info? | |
| 14:35:53 | shaohe_feng | and several interfaces, such as "def traits_report()" and "def resource_class_update" | |
| 14:35:59 | Sundar | Overall, we need to take a look at the whole flow starting with discovery/enumeration. Hope you all are following the conversation between Eric and me in openstack-dev, IRC, etc. | |
| 14:36:12 | Sundar | TShaohe, the driver/agent API spec talks about it | |
| 14:36:29 | shaohe_feng | Great. | |
| 14:36:43 | Sundar | The driver returns a structure (which should become an OVO), and the agent cna build RPs and traits out of that | |
| 14:37:24 | shaohe_feng | what's field in the OVO? | |
| 14:37:26 | xinran__ | what is OVO | |
| 14:37:37 | Sundar | I thoight about having the driver return traits directly and have the agent validate that, but that would probably make t flexible if we need to add new traits or modify existing ones | |
| 14:37:52 | Sundar | OVO == oslo versioned objects | |
| 14:38:34 | shaohe_feng | Sundar, You spec define well about different traits types. | |
| 14:38:44 | Sundar | In simple terms, OVO is a Python dictionary with well=defined schema, a version and a namespace | |
| 14:38:54 | shaohe_feng | I follow it in the POC | |
| 14:39:07 | shaohe_feng | but not define how to report it. | |
| 14:39:39 | Sundar | #lonk https://git.openstack.org/cgit/openstack/cyborg/tree/doc/specs/rocky/cyborg-agent-driver-api.rst?h=refs/changes/49/561849/7#n125 | |
| 14:40:01 | Sundar | Shaohe: Line 125 talks about function IDs and how the agent handles them | |
| 14:40:42 | Sundar | Line 99 says what the field should look like | |
| 14:40:51 | shaohe_feng | yes, I did return this format traits. | |
| 14:41:46 | Sundar | Ah, typo: #link https://git.openstack.org/cgit/openstack/cyborg/tree/doc/specs/rocky/cyborg-agent-driver-api.rst?h=refs/changes/49/561849/7#n125 | |
| 14:42:08 | shaohe_feng | But I find it is not good for agent to report the traits. | |
| 14:42:32 | shaohe_feng | For example, every devices may have different provider layers. | |
| 14:43:03 | Sundar | Yes, the spec does not talk about ho the agent reports the info to Cyborg conductor or placement, because it is a driver/agent API spec | |
| 14:44:14 | Sundar | "different provider layers" -- can you expand on that? | |
| 14:46:29 | Li_Liu | I guess it refers to different layers of pf/vfs? | |
| 14:48:08 | shaohe_feng | we list the the traits find there is a ``CUSTOM_<type>_<vendor>_FUNCTION_<function-uuid>`` | |
| 14:48:50 | wangzhh | Hi all. Sorry, I'm late... | |
| 14:49:13 | shaohe_feng | such as CUSTOM_FPGA_INTEL_FUNCTION_1234, CUSTOM_FPGA_INTEL_FUNCTION_5678 | |
| 14:49:41 | shaohe_feng | Sundar, how Dow I know which traits is my expect? | |
| 14:50:08 | shaohe_feng | I use a temporary solution. | |
| 14:50:33 | shaohe_feng | I add a uuid/name map in yaml config. | |
| 14:51:08 | shaohe_feng | such as 1234:crypto, 5678:ipsec | |
| 14:51:26 | shaohe_feng | 1234:crypto_v1.2 | |
| 14:51:56 | shaohe_feng | it support dynamically update. | |
| 14:52:27 | shaohe_feng | I also report CUSTOM_FPGA_INTEL_FUNCTION_CRYPTO_V1_2 to the placement. | |