| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-10-17 | |||
| 14:33:23 | Sundar | Think about how this even relates to the Nova spec | |
| 14:34:08 | shaohe_feng | so the summary of new cyborg design: | |
| 14:34:32 | shaohe_feng | 1. split the nova flavor to device profile | |
| 14:34:57 | shaohe_feng | 2. change the accelerator api to var api. | |
| 14:34:59 | xinran | Sundar: I can modify this spec according to your nova spec if you want once your spec is merged. | |
| 14:35:00 | shaohe_feng | right? | |
| 14:35:48 | xinran | Sundar: or you prefer to write a new one by yourself? | |
| 14:36:05 | Sundar | Xinran, Shaohe: we need to start with the Cyborg API signatures proposed for Nova, and work downwards into the details. That is what we do in https://review.openstack.org/#/c/608624/ | |
| 14:36:51 | shaohe_feng | what is signatures? | |
| 14:37:34 | Sundar | Shaohe: API parameters, responses, HTTP return codes | |
| 14:38:53 | Sundar | Shahe: re. your question about 2 parts, the device profiles are an important part. So is the whole flow about creating VARs in an unbound state, then binding them, then attaching. | |
| 14:40:23 | Sundar | Aso, the device model where we map deployables to RPs, as we discussed last week | |
| 14:41:10 | shaohe_feng | I do not care you name is var or accelerator. | |
| 14:41:35 | Sundar | A VAR is not an accelerator. | |
| 14:41:54 | shaohe_feng | but as user var is puzzle, like vport. | |
| 14:42:35 | shaohe_feng | var is used for a choose a device to bind to a VM. | |
| 14:42:35 | Sundar | "var is puzzle" -- what does that mean? | |
| 14:43:43 | Sundar | A VAR is a Virtual Accelerator Request. It abstracts the state of the request, starting from user requirements, moving on to the Nova's selection of an alloc cand with device RPs, and then Cyborg bindings | |
| 14:43:54 | shaohe_feng | any project, you seen they expose a var object to user? | |
| 14:43:58 | Sundar | This is conceptually different from what we had before the PTG | |
| 14:44:10 | shaohe_feng | vport, vvolume? | |
| 14:44:38 | Li_Liu_ | shaohe, are you more concern with the naming or the concept? | |
| 14:44:56 | shaohe_feng | the initial design, is Request a Accelerator to VM. | |
| 14:45:33 | shaohe_feng | but we does not name it virtual accelerator, we just named it accelerator | |
| 14:45:40 | shaohe_feng | no need to use virtual | |
| 14:45:52 | Sundar | Shaohe: is this about names, or concepts? | |
| 14:46:27 | shaohe_feng | no need to emphasize virtual | |
| 14:46:41 | shaohe_feng | you can discuss with Li_Liu_ about the accelerator history | |
| 14:46:43 | shaohe_feng | about the name | |
| 14:46:48 | Li_Liu_ | I think "virtual" word indeed confuses a bit | |
| 14:47:00 | wangzhh | Shaohe: Accelerator is not same as VAR. Maybe u confusion about them? | |
| 14:47:46 | Li_Liu_ | but I agree it's different from concept of accelerator | |
| 14:48:32 | Sundar | Neutron has something called a VIF -- virtual interface. The word 'virtual' is used in many contexts. I don't understand the issue. | |
| 14:50:23 | Li_Liu_ | I guess when you put all of these virtual accelerator / accelerator request / virtual accelerator request together. that's where the confusion starts | |
| 14:51:34 | Li_Liu_ | Sundar, does nova needs to care if a accelerator is virtual or not? | |
| 14:51:43 | Sundar | Li_Liu: We have accelerators and we have VARs. Former is a resource represented in Placement. VAR, as you said, is different -- it is a request for an accelerator -- not known to Placement. There are only 2 things | |
| 14:52:12 | wangzhh | I think it's better to have a clear definition of VAR. In the doc, for other developer or users. | |
| 14:52:39 | wangzhh | Sundar: Agree. | |
| 14:52:42 | Sundar | Li_Liu: Accelerators are resource class inventories -- they are not physical hardware, even in the previous Rocky proposal | |
| 14:53:41 | Sundar | Li_Liu: AFAIK, we never used the term 'virtual accelerator' to refer to an accelerator. | |
| 14:54:27 | Li_Liu_ | I know, I think Cyborg maybe should hide physical/virtual accelerator concept from nova. | |
| 14:54:47 | Li_Liu_ | or can we rename it to Accelerator Virtual Request | |
| 14:55:11 | Li_Liu_ | as, according to you, the request is virtual but not the accelerator? | |
| 14:55:18 | shaohe_feng | accelerator is OK. | |
| 14:55:51 | shaohe_feng | and Request is verb | |
| 14:56:03 | Li_Liu_ | shaohe_feng, we do have accelerator, but sunder needs something different to work with placement | |
| 14:56:23 | Sundar | Li_Liu: yes, the request is virtual. If we just call it an Accelerator Request, say ARQ or something, are you ok with that? | |
| 14:56:34 | shaohe_feng | Request and be apply to a noun accelerator | |
| 14:56:57 | shaohe_feng | Request can be apply to a noun accelerator | |
| 14:57:26 | shaohe_feng | this is not conflict with RESTFUL style. | |
| 14:57:53 | Sundar | Li_Liu: "hide physical/virtual accelerator" Please note that the term 'accelerator' never refers to any physical entity :) | |
| 14:58:50 | Sundar | In Placement, an accelerator type is a resource class (e.g. CUSTOM_ACCELERATOR_FPGA). There are number of resources of one RC in a single RP | |
| 14:58:52 | wangzhh | Sundar, could u explain the differences between Acc and VAR? I just know parts of them. I think shaohe is confused about them. | |
| 14:58:52 | Li_Liu_ | ARQ is kinda cool to me | |
| 14:59:06 | Sundar | So, it is just a number that Placement is counting as RC inventory | |
| 14:59:35 | shaohe_feng | generally, for a REST, a resource belong to a collection, and the the resource can support different verb action | |
| 15:01:02 | Li_Liu_ | btw shaohe, Request cal also be a noun | |
| 15:01:27 | shaohe_feng | so request is a resource | |
| 15:01:35 | Sundar | wangzhh: OK. Placement has the notion of Resource providers (RPs) and Resource Classes (RC). We model each accelerator type as an RC. An accelerator is a unit of offload that can be assigned individually (to a VM, container, ...) | |
| 15:01:44 | shaohe_feng | bind is verb to this request resource | |
| 15:02:33 | Li_Liu_ | shaohe_feng, I think that's Sundar's idea, is it? Sundar | |
| 15:03:08 | shaohe_feng | OK, seldom see this rest style. | |
| 15:03:15 | Sundar | VARs are indeed resources in the REST API. We apply HTTP operations like GET, POST etc. to that resource. | |
| 15:03:40 | Sundar | Shaohe: have you reviewed the Nova spec? | |
| 15:04:23 | shaohe_feng | have a look at https://review.openstack.org/#/c/608624/2/specs/stein/approved/cyborg-api-wflows-for-instance-ops.rst | |
| 15:04:36 | wangzhh | Sundar, Yes. So is there any differences on data structure? | |
| 15:04:59 | shaohe_feng | any way, virtual Accelerator Requests is puzzle me. | |
| 15:05:00 | wangzhh | Between VAR and Acc. | |
| 15:05:28 | shaohe_feng | so VARs is a collection, and var is resource. | |
| 15:05:48 | shaohe_feng | VARs means multi requests. | |
| 15:05:56 | Sundar | wangzhh: Getting back to your question :) Yes, a VAR is an OVO that is stored in Cyborg db. An accelerator is not a data structure per se: it is the inventory of a resource provider maintained by Placement n its db | |
| 15:05:58 | shaohe_feng | var is one request | |
| 15:06:05 | shaohe_feng | right? | |
| 15:07:23 | shaohe_feng | and why we need var? just for consistency？ | |
| 15:07:47 | Sundar | Yes, VAR is singular, VARs is plural. The Nova spec 603955 defines APIs on the collection VARs, so that we can do batch operations | |
| 15:10:36 | shaohe_feng | anyway, here you define the VAR is same to the accelerator concept in our initial design | |
| 15:10:44 | Sundar | No | |
| 15:10:53 | Sundar | Accelerator != VAR | |
| 15:11:06 | shaohe_feng | anyway, here you define the VAR is same to the accelerator concept in my initial design | |
| 15:11:10 | Sundar | The concept of accelerator as a RC existed from Rocky cycle | |
| 15:11:12 | wangzhh | So, when cyborg-agent started, It collects which one? I think It is acc. And VAR will be created when user want accs to attach? | |
| 15:11:15 | Sundar | VAR is new from Stein PTG | |
| 15:11:55 | shaohe_feng | and your Accelerator is same to the allocation unit in my initial design :) | |
| 15:13:24 | shaohe_feng | other's no different | |
| 15:13:28 | shaohe_feng | just name is different | |
| 15:13:36 | Sundar | wangzhh: Cyborg agent collects device (physical hardware) and accelerator info from the driver. Please see the driver report structure in https://docs.google.com/presentation/d/1Anud3Qbcb0P3G245HpHduHhslx1MJljGD6wqPDy7o9E/edit#slide=id.g44d3e3519f_4_134 | |
| 15:13:59 | shaohe_feng | OK, let go ahead for others. | |
| 15:15:00 | Sundar | I am 15 minutes into my next meeting, and it is a bit difficult to flip back and forth. I need to drop out now. | |
| 15:15:29 | Sundar | Shaohe: I am open to discussion at other times or meetings. | |
| 15:15:54 | shaohe_feng | Sundar: OK. we can also discuss it off line. | |
| 15:16:01 | shaohe_feng | Sundar: have a good day. bye. | |
| 15:20:44 | Li_Liu | ping | |
| 15:20:55 | Li_Liu | you guys still there? | |
| 15:22:06 | Li_Liu | anyone? | |
| 15:26:00 | Li_Liu | if no one is here, I will end the meeting for today | |
| 15:26:24 | Li_Liu | we can carry on the discussion offline | |
| 15:26:25 | Li_Liu | #endmeeting | |
| 15:26:27 | openstack | Meeting ended Wed Oct 17 15:26:25 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 15:26:28 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-10-17-14.06.html | |
| 15:26:29 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-10-17-14.06.txt | |