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: [email protected]<mailto:[email protected]>
Mobile: +91 9866235130 | Off: +91 4033504051
From: Dean Troyer [mailto:[email protected]]
Sent: Wednesday, April 12, 2017 10:17 PM
To: OpenStack Development Mailing List (not for usage questions)
<[email protected]>
Subject: Re: [openstack-dev] [Tacker][OSC] Command naming specs
On Wed, Apr 12, 2017 at 2:08 AM, Trinath Somanchi
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
