| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-05-09 | |||
| 15:49:22 | Li_Liu | regions are just a type of deployable | |
| 15:49:53 | sundar | I think xinran is right -- quotas are based on resource classes, right? | |
| 15:50:55 | xinran__ | sundar: yes I think so :) | |
| 15:51:24 | zhipeng | okey then we could settle upon that :) | |
| 15:51:26 | shaohe_ | sundar: only one resource type for quota? | |
| 15:51:35 | sundar | OK, then there is only one resource class in Cyborg -- CUSTOM_ACCELERATOR -- as we agreed with Nova | |
| 15:52:28 | Li_Liu | i see, that's what is exposed to nova. | |
| 15:52:53 | shaohe_ | for example, there maybe spdk software accelerators and vgpu accelerators. they share the same quotas? | |
| 15:52:56 | sundar | shaohe: I think so, but maybe I need to read more on quotas | |
| 15:53:04 | Li_Liu | xinran__ sundar their db existence are deployable just to be clear | |
| 15:53:49 | sundar | Li_Liu: when we get to oslo.limit based on Keystone, as Xinran said, that will be based on resource classes, right? | |
| 15:53:56 | shaohe_ | for nova, at present, the granularity is cpu, mem... | |
| 15:54:11 | edleafe | sundar: why just one CUSTOM_ class? The whole idea behind CUSTOM_ resource classes is that the service can create what it needs. | |
| 15:54:33 | shaohe_ | maybe gpu is also one quota | |
| 15:54:36 | Li_Liu | sundar right, deployables are just db existences. | |
| 15:54:43 | sum12 | need to drop | |
| 15:55:14 | xinran__ | I think quota should depends on resource class | |
| 15:55:14 | sundar | edleafe: this is what Nova folks proposed to us, right? :) Are we ok with CUSTOM_ACCELERATOR_FPGA, CUSTOM_ACCELERATOR_GPU, ...? | |
| 15:55:39 | shaohe_ | we should keep in mind, if we use one CUSTOM_ class, we must use nest resource provider. | |
| 15:55:49 | edleafe | sundar: I guess I missed that proposal. Was it to keep the Nova flavors simple? | |
| 15:56:10 | shaohe_ | or we can not distinguish the different resource | |
| 15:56:55 | sundar | edleafe: Multiple resource classes would actually be better. I didn't see a specific reason for single RC. Maybe the discussion was centered around vGPU types, and one was enough | |
| 15:57:27 | shaohe_ | that's the difference on flavors if we use one CUSTOM_ class or multi CUSTOM_ class? | |
| 15:57:58 | edleafe | sundar: that sounds more correct. As shaohe_ notes, if I ask for CUSTOM_ACCELERATOR, I might get back an FPGA or a GPU. :) | |
| 15:58:36 | sundar | edleafe: we have traits that distinguish FPGAs of different types, GPUs of different types, ... | |
| 15:58:55 | sundar | So, the flavor would ask for the traits too, as noted in the spec | |
| 15:59:20 | sundar | But, for quotas, it would be better to have distinct RCs based on device type (FPGA, GPU, HPTS, ....) | |
| 15:59:22 | xinran__ | I also feel a little bit confused why there is only one resource class but anyway quota should accord to resource class right? | |
| 16:00:04 | zhipeng | Li_Liu any input ? | |
| 16:00:13 | shaohe_ | so for one CUSTOM_ class, it should be nest PR first, and the flavor should be: resources:CUSTOM_ACCELERATOR:1, traits: FPGA | |
| 16:00:44 | shaohe_ | for multi CUSTOM_ class, the flavor should be: resources:CUSTOM_FPGA:1 | |
| 16:00:58 | shaohe_ | for multi CUSTOM_ class, the flavor should be: resources:CUSTOM_GPU:1 | |
| 16:01:29 | shaohe_ | ^ edleafe: right? | |
| 16:01:32 | sundar | shaohe: yes, you are right. We don't need nested RPs for this flavor definition. | |
| 16:01:54 | edleafe | It would be better, IMO, to have separate resource classes to distinguish the different devices (GPU vs. FPGA), and use traits to further refine the capabilities of a particular device | |
| 16:02:00 | sundar | But that will introduce limitations on combining different device tyoes | |
| 16:02:23 | sundar | edleafe: Agreed. Let me amend the spec. Please review it! | |
| 16:02:29 | shaohe_ | multi CUSTOM_ class can work without NPR. | |
| 16:02:48 | shaohe_ | one CUSTOM_ class must work with NPR | |
| 16:02:48 | edleafe | sundar: ack | |
| 16:03:08 | sundar | shaohe: multi CUSTOM_ class without nRPs will also have issues if you combine 2 different FPGAs on same host | |
| 16:03:24 | Li_Liu | zhipeng as far as I concern, using CUSTOM_ACCELERATOR might be a bit too general, if we decide to use it, additional information will be need to schedule/allocate the resources | |
| 16:03:51 | xinran__ | Li_Liu: like traits? | |
| 16:04:13 | zhipeng | will the way shaohe_ just mentioned work ? | |
| 16:04:28 | Li_Liu | right. coz essentially, we want to guide nova during their scheduling. | |
| 16:04:32 | sundar | We will not create RCs like CUSTOM_ACCELERATOR_FPGA_INTEL_ARRIA10, but only CUSTOM_ACCELERATOR_FPGA, CUSTOM_ACCELERATOR_GPU, etc. | |
| 16:04:38 | shaohe_ | xinran__: yes, it need traits on sub resource provider. | |
| 16:04:59 | Li_Liu | shaohes's way should work | |
| 16:05:43 | sundar | shaohe and all: I have been tracking nRP support in Nova, and apparently we are a week or two away from getting it. edleafe can confirm :) So, maybe we don't have to split hairs over what to do without nRP ;) | |
| 16:06:29 | sundar | Even with CUSTOM_ACCELERATOR_FPGA etc., we still need traits | |
| 16:07:03 | shaohe_ | but we can not need nPR. | |
| 16:07:48 | sundar | Sorry, late for my next meeting. I'll do my reviews offline and catch up here. :) | |
| 16:08:30 | edleafe | it does seem that nested RPs may be merged soon | |
| 16:09:04 | shaohe_ | edleafe: good. Then one CUSTOM_ class can works. | |
| 16:09:34 | zhipeng | sounds very promising :) | |
| 16:09:38 | edleafe | shaohe_: sure, it *can* work, but it isn't really a good design | |
| 16:10:03 | sundar | shaohe: multiple classes are good for quotas | |
| 16:10:36 | NokMikeR | Sorry Howard I have to leave physically but will leave this on monitoring. Best of luck sleeping :) | |
| 16:11:19 | zhipeng | NokMikeR :) no problem | |
| 16:11:39 | shaohe_ | edleafe: I have no objection on one CUSTOM_ class after we support nPR | |
| 16:11:58 | zhipeng | okey so since this is a spec review day, Li_Liu sundar plz continue discuss your specs here and I will leave the meeting recorded throughout the day | |
| 16:12:43 | xinran__ | Anyway I think quota should be accord with RCs... if one RC, quota count one... | |
| 16:14:41 | Li_Liu | I am gonna grab some lunch, we can discuss this later today | |
| 16:14:52 | Li_Liu | I will keep my session open | |
| 16:15:08 | Li_Liu | @sundar and all | |
| 16:20:05 | sundar | Sorry, guys. I am jumping between my meeting and here. I will keep it open too. | |
| 16:28:36 | edleafe | zhipengh[m]: you forgot to #endmeeting | |
| 16:29:47 | zhipengh[m] | That is on purpose :) | |
| 16:34:38 | sundar | Li_Liu: I am getting customer feedback that some of them want to use function names in Rocky. The problem is that FPGA hardware and bitstreams may expose function IDs, not names. | |
| 16:35:39 | sundar | So, one possibility is to let the operator apply a Glance property for function name when he onboards a bitstream, and reference that in the flavor. For Cyborg, it is just another Glance property to query -- wheher it is function ID or name. | |
| 16:35:51 | sundar | What do you think? | |
| 18:15:03 | Li_Liu | sundar, I added function_uuid based on your comments for the metadata spec. That uuid should be mapped to a specific function name | |
| 18:56:57 | sundar | Li_Liu: yes. At least for Rocky, we can leave that mapping to the operator. | |
| 18:59:06 | sundar | IOW, the traits we apply are still based only on UUIDs. No further complexity in Rocky | |
| 19:00:22 | sundar | Can you add a function name as an optional property in your spec? | |
| 19:11:46 | Li_Liu | sundar sure will do | |
| 19:40:36 | sundar | Li_Liu: Thanks! | |
| #openstack-cyborg - 2018-05-10 | |||
| 02:29:00 | openstackgerrit | Nguyen Van Trung proposed openstack/cyborg master: Add doc8 to pep8 check for cyborg project https://review.openstack.org/567457 | |
| 23:36:38 | openstackgerrit | Sundar Nadathur proposed openstack/cyborg master: Specification for Cyborg/Nova interaction for scheduling. https://review.openstack.org/554717 | |
| #openstack-cyborg - 2018-05-12 | |||
| 01:53:56 | openstackgerrit | Li Liu proposed openstack/cyborg master: Added bitstream metadata standardization spec https://review.openstack.org/558265 | |
| 17:48:30 | shellfishers | TESTING TESTING | |
| #openstack-cyborg - 2018-05-14 | |||
| 02:33:40 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Quota usage support in Cyborg https://review.openstack.org/564968 | |
| 02:34:42 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Quota usage support in Cyborg https://review.openstack.org/564968 | |
| 02:35:33 | zhipeng | #endmeeting | |
| 08:30:05 | openstackgerrit | ShangXiao proposed openstack/cyborg master: Add documentation links to README https://review.openstack.org/568230 | |
| 09:20:29 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Quota usage support in Cyborg https://review.openstack.org/564968 | |
| 10:04:53 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Introduce Cyborg Resource Quota -- Usage Part https://review.openstack.org/560285 | |
| 10:52:20 | openstackgerrit | Merged openstack/cyborg master: Add doc8 to pep8 check for cyborg project https://review.openstack.org/567457 | |
| 14:01:21 | shaohe_feng | #startmeeting openstack-cyborg-driver | |
| 14:01:22 | openstack | Meeting started Mon May 14 14:01:21 2018 UTC and is due to finish in 60 minutes. The chair is shaohe_feng. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 14:01:24 | openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 14:01:26 | openstack | The meeting name has been set to 'openstack_cyborg_driver' | |
| 14:01:50 | shaohe_feng | #topic Roll Call | |
| 14:02:10 | shaohe_feng | #info shaohe | |
| 14:02:20 | xinran__ | #info xinran__ | |
| 14:02:26 | Li_Liu | #Li_Liu | |
| 14:02:28 | Helloway | #info Helloway | |
| 14:02:31 | Li_Liu | #info Li_Liu | |
| 14:03:11 | sundar_ | #info Sundar | |
| 14:03:12 | shaohe_feng | sundar_: morning. | |