Open Stack

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>:

> 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 <trinath.somanchi at nxp.com>*
>
> Mobile: +91 9866235130 <+91%2098662%2035130> | Off: +91 4033504051
> <+91%2040%203350%204051>
>
> [image: cid:image001.png at 01D28854.B7934C80]
>
>
>
> *From:* Dean Troyer [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>
> *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> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at 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/ab773257/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 450 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170413/ab773257/attachment-0001.png>