| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-05-09 | |||
| 15:25:38 | edleafe | 'accelerator' is a known term for computers. | |
| 15:25:43 | edleafe | 'accel' not so much | |
| 15:25:45 | shaohe_ | openstack command support bash completion | |
| 15:26:13 | sundar | sum12: with bash completion, do you still see a problem with 'accelerator'? | |
| 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, ... | |