Posted	Nick	Remark
#openstack-cyborg - 2018-05-09
15:33:54	sum12	:)
15:34:19	shaohe_	let's show the command:
15:34:20	shaohe_	$ openstack --help |grep flavor
15:34:31	shaohe_	flavor create Create new flavor
15:34:40	shaohe_	network flavor create Create new network flavor
15:34:50	shaohe_	there are two flavor,
15:35:19	shaohe_	first one is nova flavor
15:35:19	sundar	Shaohe: why should Cyborg commands create flavors? Flavors with accelerators should still be under usual command, right? In any case, we can do 'openstack accelerator create flavor ...'
15:35:35	shaohe_	second one is network flavor.
15:36:03	sundar	shaohe: ok. we can do 'openstack accelerator create flavor ...'
15:36:37	shaohe_	sundar: but openstack accelerator create flavor is not formal
15:37:21	shaohe_	for accelerator is just an collection of our restful url.
15:38:12	shaohe_	and accelerations is the service type. we register in keystone
15:38:25	sundar	shaohe: Not sure what you mean by 'formal'. If you prefer 'openstack accelerator flavor create', like nova/network, I am fine.
15:38:50	zhipeng	shaohe_ i think let's just change it to accelerator
15:38:59	zhipeng	seems like a team consensus at the moment
15:39:18	zhipeng	after that update the patch should good to go :)
15:39:57	shaohe_	zhipeng: OK, so we register in keystone use accelerator instead of acceleration?
15:40:00	sundar	There were some deprecated code in that patch
15:40:16	shaohe_	sundar: I will remove them
15:40:25	sundar	Thanks, shaohe
15:40:33	zhipeng	shaohe- yes I guess so
15:41:16	shaohe_	OK, let me file a patch to correct the service type firstly.
15:41:52	zhipeng	many thx :)
15:41:58	zhipeng	ok given the time in China
15:42:00	zhipeng	xiran_
15:42:12	zhipeng	could you provide a update on the quota spec ?
15:42:16	zhipeng	xinran_
15:42:41	zhipeng	#info Quota spec
15:42:49	zhipeng	#link https://review.openstack.org/560285
15:42:59	zhipeng	#link https://review.openstack.org/564968
15:44:53	sundar	Is this the Keystone-based quota that we were recommended to use?
15:45:03	xinran__	Yes i have update the spec firstly we should support quota usage in cyborg and implement limit part by invoke Oslo.limit once keystone guys finish that
15:46:42	xinran__	I have a doubt about resource type. Should we just count total number of accelerator or should we count like fpga gpu etc
15:47:11	Li_Liu	We count the number of deployables I think
15:47:29	zhipeng	Li_Liu shall we count them per type ?
15:47:42	sundar	Li_Liu: A FPGA, as well as regions with it, will all be Deployables, right?
15:47:44	shaohe_	count granularity
15:48:08	Li_Liu	yes, they should be grouped in types for sure
15:48:29	xinran__	zhipeng: seems there is only one resource class(accelerator) for now
15:48:57	sundar	S, the quota be based on Deployable type? i.e. you can get X regions
15:49:04	Li_Liu	the deployable patch has already been merged
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 :)

Earlier   Later