| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-05-09 | |||
| 15:10:45 | shaohe_ | cyborg is project name, acceleration is service type. | |
| 15:10:46 | edleafe | yeah - project names should be avoided | |
| 15:11:00 | NokMikeR | clarified thanks. | |
| 15:11:14 | Li_Liu | that's good to know :) | |
| 15:11:42 | sundar | shaohe: It is not clear to me why we cannot have 'openstack accelerator <list/show/...>' | |
| 15:12:03 | zhipeng | sundar see my above comment | |
| 15:12:09 | zhipeng | because accelerator more like an object that we will choose to act upon | |
| 15:12:24 | zhipeng | acceleration is a type of service, like server service, volume service | |
| 15:12:46 | sundar | zhipeng, yes. Like server/image etc. shouldn't it be the 2nd arg? | |
| 15:12:54 | zhipeng | we might have something like openstack acceleration fpga create | |
| 15:13:15 | zhipeng | shaohe_ correct me if I'm wrong | |
| 15:13:32 | shaohe_ | yes. I have look other project. | |
| 15:13:48 | shaohe_ | they do use this syntax | |
| 15:14:01 | shaohe_ | some use this syntax | |
| 15:14:07 | NokMikeR | is it command(create) then object(fpga) ? | |
| 15:15:05 | NokMikeR | openstack [<global-options>] <object-1> <action> [<object-2>] [<command-arguments>] | |
| 15:15:25 | shaohe_ | yes as NokMikeR suggestion | |
| 15:15:37 | zhipeng | NokMikeR yes the example i mentioned might not be strictly correct :P | |
| 15:15:40 | shaohe_ | global-options can be service type | |
| 15:16:12 | shaohe_ | for cyborg the service type is acceleration. | |
| 15:16:29 | shaohe_ | for cinder the service type is volume | |
| 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 ...' | |