Posted	Nick	Remark
#openstack-cyborg - 2018-05-09
15:27:12	shaohe_	oh, sorry
15:27:19	shaohe_	volume type create Create new volume type
15:27:27	shaohe_	volume snapshot create Create new volume snapshot
15:27:33	sum12	bash completion is not a problem, but if I was devops guy I like the small and easy to remember (scripting) and not too charachter-y
15:27:37	NokMikeR	https://docs.openstack.org/python-openstackclient/latest/ they are listed here
15:28:16	NokMikeR	https://docs.openstack.org/python-openstackclient/latest/cli/commands.html
15:28:21	sundar	From the link by NokMikeR: $ volume type list # 'volume type' is a two-word single object
15:28:22	shaohe_	$ openstack volume type create --help
15:28:43	shaohe_	usage: openstack volume type create [-h] [-f {json,shell,table,value,yaml}]
15:29:03	edleafe	sum12: at least it isn't as long as 'application credential' :)
15:29:31	sum12	edleafe: :)
15:29:49	zhipeng	do we have a consensus now ? :)
15:29:50	shaohe_	sundar: yes, it is two-word single object
15:30:12	shaohe_	and volume is the service type.
15:30:14	sundar	We have a single-word single object :) which is better
15:30:50	sundar	Anyways, I vote for 'openstack accelerator <command> <object-2> ...' That's my 2 cents
15:31:56	zhipeng	i vote for that as well
15:32:07	NokMikeR	same here if Im allowed.
15:32:32	shaohe_	OK, remove the service type.
15:32:39	shaohe_	but keep in mind
15:33:04	kosamara	I would prefer accelerator too
15:33:12	shaohe_	if cyborg support a flavor api
15:33:23	shaohe_	flavor create/list
15:33:27	shaohe_	what should it be?
15:33:33	zhipeng	sum12 that word looks a bit shorter now ? lol
15:33:35	shaohe_	^ sundar:
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

Earlier   Later