| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-05-09 | |||
| 15:20:16 | edleafe | ^^ what sundar said | |
| 15:21:06 | zhipeng | ya I'm just thinking when we actually using accelerator it will need to be more specific (FPGA, GPU, ...) | |
| 15:21:24 | zhipeng | acceleration could just represent a service type offered by cyborg in general | |
| 15:21:26 | shaohe_ | sundar: edleafe: $ openstack --help |grep volume | |
| 15:21:35 | xinran__ | Yes I think accelerator is more reasonable | |
| 15:21:52 | sundar | zhipeng: yes, openstack accelerator create fpga <args> -- here 'fpga' is 'object-2' | |
| 15:21:55 | NokMikeR | acceleration implies more than one device? accelerator is singular or one device. If we debate this to the end we end up somewhere in particle physics... :) | |
| 15:22:09 | zhipeng | haha NokMikeR | |
| 15:22:17 | zhipeng | but I think accelerator has more votes here | |
| 15:22:31 | sum12 | i feel accelerator/acceleration are both too complicated as compared to service/image/network/... | |
| 15:22:47 | zhipeng | sum12 lol what is your suggestion | |
| 15:23:26 | sum12 | I am suggesting to ask we we anything easier in out arsenal ? | |
| 15:23:44 | zhipeng | maybe just acc ? | |
| 15:23:54 | shaohe_ | sum12: acc for abbreviation？ | |
| 15:24:07 | sundar | sum12: we use the term 'accelerator' or 'device'. But the term device is too general? | |
| 15:24:07 | zhipeng | shaohe_ man crush | |
| 15:24:25 | sum12 | accel ? | |
| 15:24:25 | zhipeng | sundar ya that might give people confusion | |
| 15:24:38 | zhipeng | accel a little bit too Xilinx-ish ? | |
| 15:24:43 | sundar | sum12: accel is ok by me. I use that abbrev too | |
| 15:24:52 | zhipeng | okey anyone else ? | |
| 15:25:15 | zhipeng | if accel could work then accel it is :) | |
| 15:25:16 | sundar | If we give bash completions | |
| 15:25:33 | sundar | If we provide bash completions, it may not matter :) | |
| 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 | |