Earlier  
Posted Nick Remark
#openstack-cyborg - 2018-05-09
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 shaohe_ openstack network --help |less
15:18:52 sundar If everybody else is ok with it, I am ok too :)
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 zhipeng shaohe_ man crush
15:24:07 sundar sum12: we use the term 'accelerator' or 'device'. But the term device is too general?
15:24:25 zhipeng sundar ya that might give people confusion
15:24:25 sum12 accel ?
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 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:19 shaohe_ first one is nova 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

Earlier   Later