Earlier  
Later
New Search
Posted Nick Remark
#openstack-cyborg - 2018-05-09
15:26:47 shaohe_ let see cinder's command name
15:26:48 shaohe_ $ openstack --help |grep volume
15:27:04 shaohe_ volume type create Create new volume type volume type delete Delete volume type(s) volume type list List volume types volume type set Set volume type properties volume type show Display volume type details volume type unset Unset volume type properties volume unset Unset volume properties
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 ?

Earlier   Later