Thanks Akihiro for suggestions and comments. Thanks, Trinath Somanchi. Digital Networking | NXP – Hyderabad – INDIA. Email: trinath.soman...@nxp.com<mailto:trinath.soman...@nxp.com> Mobile: +91 9866235130 | Off: +91 4033504051
From: Akihiro Motoki [mailto:amot...@gmail.com] Sent: Thursday, April 13, 2017 8:17 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Tacker][OSC] Command naming specs networking-sfc has many overlapping areas with tacker and the command names can conflict, so I believe it is worth shared in this thread. networking-sfc team is now implementing OSC commands (as neutronclient OSC plugin). Their command name proposal can be found at https://review.openstack.org/#/c/409759/ and command names are like https://review.openstack.org/#/c/409759/30/doc/source/usage/osc/v2/networking-sfc.rst As of now, networking-sfc commands are like: openstack sfc port chain create openstack sfc port pair group create openstack sfc port pair create openstack sfc flow classifier create We would like to use 'sfc' (or 'network sfc') and hope the tacker team avoid conflicts and confusions between tacker and networking-sfc commands. Personally, 'sfc' is not a well-known abbreviation, but the full spelling 'service function chaining' looks too long. I don't think users want to type 'openstack service function chaining port chain group create'.... :-( It loses usability significantly. Thanks, Akihiro 2017-04-13 8:23 GMT+09:00 Trinath Somanchi <trinath.soman...@nxp.com<mailto:trinath.soman...@nxp.com>>: But if we don’t prefix, then we are afraid we might confuse users with command names and conflict with other projects. Example, ‘network-service’ if we follow the existing way, then $> openstack network service create might confuse the user in context that it’s a neutron/networking command. Is that not True? Also, for some other commands, like sfc, we might end up conflict with networking-sfc. Like, $> openstack sfc show (or) openstack service function chain show With some of the other commands, there are abbreviations like $> openstack vnffgd create If the above command must be split to words, it spells like, $> openstack virtual network function forwarding graph descriptor create <other_args > If we elaborate this way the command itself will be a lengthy string where user has a very lengthy command. Any suggestions for these? Thanks, Trinath Somanchi. Digital Networking | NXP – Hyderabad – INDIA. Email: trinath.soman...@nxp.com<mailto:trinath.soman...@nxp.com> Mobile: +91 9866235130<tel:+91%2098662%2035130> | Off: +91 4033504051<tel:+91%2040%203350%204051> From: Dean Troyer [mailto:dtro...@gmail.com<mailto:dtro...@gmail.com>] Sent: Wednesday, April 12, 2017 10:17 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Tacker][OSC] Command naming specs On Wed, Apr 12, 2017 at 2:08 AM, Trinath Somanchi <trinath.soman...@nxp.com<mailto:trinath.soman...@nxp.com>> wrote: Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the prefix. Note that OSC itself does not use 'command prefixes', it names resources with enough specificity to make them unique. Sometimes that looks like a proefix, but it is not. For the below commands, for readability, we have added ‘-‘ within the command names. Like, network-service, vnf-forwarding-graph, service-function-chain, network-flow-classifier, network-forwarding-path. But the existing OSC commands don’t have a ‘-‘ in between the command names. The OSC command structure specifically does not use dashes or underscores as separators, it uses spaces. We want commands to be words. Dashes are only used in option names due to option parsing rules. Specifically in networking there are a large number of resources that are hard to concisely name. Plugins are of course free to do what they want but we encourage them to use the OSC guidelines, and we know that users _really_ appreciate staying consistent. There are places where you may feel forced to use abbreviations ('vnf' in your example above). Those are discouraged, but we also recognize that they are often the most common usage ('IP' in IP address for example) and where that usage is common is fine. Again, networking is an area where many things are commonly known only by their abbreviation, and this usage is in fact expected by users. In the end, picking commands that are what users would expect to search for is what they appreciate the most. dt -- Dean Troyer dtro...@gmail.com<mailto:dtro...@gmail.com> __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
