| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-05-09 | |||
| 15:16:43 | edleafe | #link openstackclient guidelines: https://docs.openstack.org/python-openstackclient/3.4.1/humaninterfaceguide.html#command-structure | |
| 15:16:44 | shaohe_ | for glance the service type is image | |
| 15:16:47 | sundar | shaohe: May be I still have a disconnect. :) "openstack [<global-options>] <object-1> <action> [<object-2>] [<command-arguments>]" Where is the service here? | |
| 15:17:11 | edleafe | sundar: object-1 | |
| 15:18:06 | sundar | So, we will have syntax like 'openstack acceleration create <object-2> ...' | |
| 15:18:49 | zhipeng | something like that | |
| 15:18:52 | sundar | If everybody else is ok with it, I am ok too :) | |
| 15:18:52 | shaohe_ | openstack network --help |less | |
| 15:19:07 | edleafe | I would suggest s/acceleration/accelerator | |
| 15:19:15 | shaohe_ | openstack network flavor create | |
| 15:19:52 | zhipeng | edleafe any reason for that ? | |
| 15:20:04 | sundar | IMHO, the term 'accelerator' is more in line with other usages -- but go ahead :) | |
| 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 | |