[openstack-dev] [Tacker][OSC] Command naming specs

Trinath Somanchi trinath.somanchi at nxp.com
Thu Apr 13 08:09:53 UTC 2017


Thanks Akihiro for suggestions and comments.
Thanks,
Trinath Somanchi.

Digital Networking | NXP – Hyderabad – INDIA.
Email: trinath.somanchi at nxp.com<mailto:trinath.somanchi at nxp.com>
Mobile: +91 9866235130 | Off: +91 4033504051


From: Akihiro Motoki [mailto:amotoki at gmail.com]
Sent: Thursday, April 13, 2017 8:17 AM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at 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.somanchi at nxp.com<mailto:trinath.somanchi at 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.somanchi at nxp.com<mailto:trinath.somanchi at nxp.com>
Mobile: +91 9866235130<tel:+91%2098662%2035130> | Off: +91 4033504051<tel:+91%2040%203350%204051>


From: Dean Troyer [mailto:dtroyer at gmail.com<mailto:dtroyer at gmail.com>]
Sent: Wednesday, April 12, 2017 10:17 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Tacker][OSC] Command naming specs

On Wed, Apr 12, 2017 at 2:08 AM, Trinath Somanchi <trinath.somanchi at nxp.com<mailto:trinath.somanchi at 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
dtroyer at gmail.com<mailto:dtroyer at gmail.com>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170413/8b964147/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 450 bytes
Desc: image001.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170413/8b964147/attachment.png>


More information about the OpenStack-dev mailing list