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

[Jay Pipes]

On 04/17/2017 07:46 PM, Sridhar Ramaswamy wrote:

I like this suggestion. Keyword 'vnf' is the closest to the unit of
things orchestrated by Tacker. Building on that we can have,

openstack vnf create - /create a single VNF based on TOSCA template/
openstack vnf service create - /create a service using a collection of VNFs/
openstack vnf graph create - /create a forwarding graph using a
collection of VNFs/


++ That is concise and easy to understand/read.


It is not an overlap per-se, it is more at a different abstraction
level. The later is a general purpose, lower-level SFC API based on
neutron ports. Former is a higher level YAML (TOSCA) template based
description of a SFC specially geared for NFV use-cases - implemented
using the lower-level networking-sfc APIs. It is analogous to Heat
OS::Nova::Server <-> Nova Compute APIs.


Understood, thanks for the clarification Sridhar!

Best,
-jay

__
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

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

[Sridhar Ramaswamy]

Hi Jay,

See inline ...

On Fri, Apr 14, 2017 at 12:25 PM, Jay Pipes  wrote:

> On 04/12/2017 03:08 AM, Trinath Somanchi wrote:
>
>> Hi OSC team-
>>
>> While  implementing tacker-cli commands as OSC plugins [1], We are
>> struck in command naming specifications.
>>
>> Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the
>> prefix.
>>
>
> It's not *all* of NFV, though.
>

I agree 'nfv' is an umbrella term and it has significance for other
projects as well (like nova).


>
> This problem, by the way, is an indication that Tacker might have too big
> a scope...and a scope that is very much tailored/purpose-built for
> Telcos/NFV. But whatever, I raised this concern during the project
> application as a member of the TC and folks ignored me, so it is what it is
> I guess.


Will stay away from this as we have thrashed this 'scope' question enough
in the TC discussions :)

However, one thing we are forcing ourselves is not use the 'network' as
initial keyword as it clearly belongs in the realm of neutron and its
associated features. What we are looking for is a term like "stack" that
indicates Orchestration (via Heat project) that we slide under.


>
> We were struck in naming the below commands while aligning with the OSC
>> naming specs.
>>
>> 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.
>>
>
> I think what Dean and Akihiro were suggesting is to use "vnf" as the first
> "word" in the command list and then use space-delimited commands like so:
>
> openstack vnf network service create
>
> Or just leave off the "network" above, because, well, Tacker doesn't
> create any other type of service..., so:
>
> openstack vnf service create
>


I like this suggestion. Keyword 'vnf' is the closest to the unit of things
orchestrated by Tacker. Building on that we can have,

openstack vnf create - *create a single VNF based on TOSCA template*
openstack vnf service create - *create a service using a collection of VNFs*
openstack vnf graph create - *create a forwarding graph using a collection
of VNFs*
...


>
> and then
>
> openstack vnf forwardinggraph create
>
> and
>
> openstack vnf service function chain create
>
> but then, you'll hit on the obvious overlap with networking-sfc, which
> will bring in the obvious question of "what's the difference between
> Tacker's SFC and networking-sfc's SFC?" which again should lead folks to
> question the scope of Tacker in relation to other OpenStack projects...
>

It is not an overlap per-se, it is more at a different abstraction level.
The later is a general purpose, lower-level SFC API based on neutron ports.
Former is a higher level YAML (TOSCA) template based description of a SFC
specially geared for NFV use-cases - implemented using the lower-level
networking-sfc APIs. It is analogous to Heat OS::Nova::Server <-> Nova
Compute APIs.

- Sridhar


>
> Best,
> -jay
>
>
> __
> 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
>
__
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

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

[Trinath Somanchi]

Agree. Vnffg can be moved as 'vnf forwardinggraph'. Also, we are discussing to 
improve the command readability from an user perspective. 


Thanks,
Trinath Somanchi.

Digital Networking | NXP – Hyderabad – INDIA.
Email: trinath.soman...@nxp.com
Mobile: +91 9866235130 | Off: +91 4033504051


-Original Message-
From: Akihiro Motoki [mailto:amot...@gmail.com] 
Sent: Monday, April 17, 2017 12:32 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Tacker][OSC] Command naming specs

2017-04-15 12:44 GMT+09:00 Trinath Somanchi <trinath.soman...@nxp.com>:
> Hi Jay-
>
> Thanks for the suggestions, we have improved this to an extent [1].
>
> For  'openstack vnf service function chain create' we agreed to go 
> with, 'openstack nfv chain create' or 'openstack vnf chain create'

I agree with Jay that NFV sounds too broad.
Even though tacker's scope can cover VNF-M and NFV-O, 'nfv' still sound too 
broad to me.
If a command belongs to VNF area, I would suggest to use 'vnf'.
If you have 'nfvo' related commands, you can explore an appropriate word.

VNFM and NFVO are different layers in ETSI and for example I am not sure 'VNF' 
forwarding graph can be called as 'NFV' forwarding graph.

> For ' openstack vnf forwardinggraph create' , you suggestion sounds 
> good. We are thinking on 'openstack vnffg create' in simple terms.

I don't think 'fg' is a common word. It is a bit long but 'forwarding graph' is 
much easier to understand.
'vnffg' is difficult to understand even though I think I know NFV to some 
extent.
Command line completion helps you. You should not think from the developer 
perspective.

Thanks,
Akihiro

> We have come up with a rule for certain commands which conflict with 
> other OpenStack projects,'nfv' is prefixed to differentiate the commands.
>
> The commands that may conflict include ``network-service``, 
> ``classifier``, ``nfp``, ``chain`` and ``event``.
>
> [1]
> https://review.openstack.org/#/c/455188/14/specs/pike/python-openstack
> client.rst
>
> Thanks,
>
> Trinath Somanchi.
>
>
>
> Digital Networking | NXP – Hyderabad – INDIA.
>
> Email: trinath.soman...@nxp.com
>
> Mobile: +91 9866235130 | Off: +91 4033504051
>
>
>
>
>
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Saturday, April 15, 2017 12:55 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Tacker][OSC] Command naming specs
>
>
>
> On 04/12/2017 03:08 AM, Trinath Somanchi wrote:
>
>> Hi OSC team-
>
>>
>
>> While  implementing tacker-cli commands as OSC plugins [1], We are
>
>> struck in command naming specifications.
>
>>
>
>> Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the
>
>> prefix.
>
>
>
> It's not *all* of NFV, though.
>
>
>
> This problem, by the way, is an indication that Tacker might have too 
> big a scope...and a scope that is very much tailored/purpose-built for 
> Telcos/NFV.
> But whatever, I raised this concern during the project application as 
> a member of the TC and folks ignored me, so it is what it is I guess.
>
>
>
>> We were struck in naming the below commands while aligning with the
>
>> OSC naming specs.
>
>>
>
>> 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.
>
>
>
> I think what Dean and Akihiro were suggesting is to use "vnf" as the 
> first "word" in the command list and then use space-delimited commands like 
> so:
>
>
>
> openstack vnf network service create
>
>
>
> Or just leave off the "network" above, because, well, Tacker doesn't 
> create any other type of service..., so:
>
>
>
> openstack vnf service create
>
>
>
> and then
>
>
>
> openstack vnf forwardinggraph create
>
>
>
> and
>
>
>
> openstack vnf service function chain create
>
>
>
>
>
> but then, you'll hit on the obvious overlap with networking-sfc, which 
> will bring in the obvious question of "what's the difference between 
> Tacker's SFC and networking-sfc's SFC?" which again should lead folks 
> to question the scope of Tacker in relation to other OpenStack projects...
>
>
>
> Best,
>
> -jay
>
>
>
> ___

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

[Akihiro Motoki]

2017-04-15 12:44 GMT+09:00 Trinath Somanchi <trinath.soman...@nxp.com>:
> Hi Jay-
>
> Thanks for the suggestions, we have improved this to an extent [1].
>
> For  'openstack vnf service function chain create' we agreed to go with,
> 'openstack nfv chain create' or 'openstack vnf chain create'

I agree with Jay that NFV sounds too broad.
Even though tacker's scope can cover VNF-M and NFV-O, 'nfv' still
sound too broad to me.
If a command belongs to VNF area, I would suggest to use 'vnf'.
If you have 'nfvo' related commands, you can explore an appropriate word.

VNFM and NFVO are different layers in ETSI and
for example I am not sure 'VNF' forwarding graph can be called as
'NFV' forwarding graph.

> For ' openstack vnf forwardinggraph create' , you suggestion sounds good. We
> are thinking on 'openstack vnffg create' in simple terms.

I don't think 'fg' is a common word. It is a bit long but 'forwarding
graph' is much easier to understand.
'vnffg' is difficult to understand even though I think I know NFV to
some extent.
Command line completion helps you. You should not think from the
developer perspective.

Thanks,
Akihiro

> We have come up with a rule for certain commands which conflict with other
> OpenStack projects,'nfv' is prefixed to differentiate the commands.
>
> The commands that may conflict include ``network-service``, ``classifier``,
> ``nfp``, ``chain`` and ``event``.
>
> [1]
> https://review.openstack.org/#/c/455188/14/specs/pike/python-openstackclient.rst
>
> Thanks,
>
> Trinath Somanchi.
>
>
>
> Digital Networking | NXP – Hyderabad – INDIA.
>
> Email: trinath.soman...@nxp.com
>
> Mobile: +91 9866235130 | Off: +91 4033504051
>
>
>
>
>
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Saturday, April 15, 2017 12:55 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Tacker][OSC] Command naming specs
>
>
>
> On 04/12/2017 03:08 AM, Trinath Somanchi wrote:
>
>> Hi OSC team-
>
>>
>
>> While  implementing tacker-cli commands as OSC plugins [1], We are
>
>> struck in command naming specifications.
>
>>
>
>> Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the
>
>> prefix.
>
>
>
> It's not *all* of NFV, though.
>
>
>
> This problem, by the way, is an indication that Tacker might have too big a
> scope...and a scope that is very much tailored/purpose-built for Telcos/NFV.
> But whatever, I raised this concern during the project application as a
> member of the TC and folks ignored me, so it is what it is I guess.
>
>
>
>> We were struck in naming the below commands while aligning with the
>
>> OSC naming specs.
>
>>
>
>> 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.
>
>
>
> I think what Dean and Akihiro were suggesting is to use "vnf" as the first
> "word" in the command list and then use space-delimited commands like so:
>
>
>
> openstack vnf network service create
>
>
>
> Or just leave off the "network" above, because, well, Tacker doesn't create
> any other type of service..., so:
>
>
>
> openstack vnf service create
>
>
>
> and then
>
>
>
> openstack vnf forwardinggraph create
>
>
>
> and
>
>
>
> openstack vnf service function chain create
>
>
>
>
>
> but then, you'll hit on the obvious overlap with networking-sfc, which will
> bring in the obvious question of "what's the difference between Tacker's SFC
> and networking-sfc's SFC?" which again should lead folks to question the
> scope of Tacker in relation to other OpenStack projects...
>
>
>
> Best,
>
> -jay
>
>
>
> __
>
> 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
>
>
> __
> 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
>

__
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

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

[Trinath Somanchi]

Hi Jay-



Thanks for the suggestions, we have improved this to an extent [1].


For  'openstack vnf service function chain create' we agreed to go with, 
'openstack nfv chain create' or 'openstack vnf chain create'

For ' openstack vnf forwardinggraph create' , you suggestion sounds good. We 
are thinking on 'openstack vnffg create' in simple terms.

We have come up with a rule for certain commands which conflict with other 
OpenStack projects,'nfv' is prefixed to differentiate the commands.
The commands that may conflict include ``network-service``, ``classifier``, 
``nfp``, ``chain`` and ``event``.



[1] 
https://review.openstack.org/#/c/455188/14/specs/pike/python-openstackclient.rst



Thanks,

Trinath Somanchi.



Digital Networking | NXP – Hyderabad – INDIA.

Email: trinath.soman...@nxp.com

Mobile: +91 9866235130 | Off: +91 4033504051





-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Saturday, April 15, 2017 12:55 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Tacker][OSC] Command naming specs



On 04/12/2017 03:08 AM, Trinath Somanchi wrote:

> Hi OSC team-

>

> While  implementing tacker-cli commands as OSC plugins [1], We are

> struck in command naming specifications.

>

> Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the

> prefix.



It's not *all* of NFV, though.



This problem, by the way, is an indication that Tacker might have too big a 
scope...and a scope that is very much tailored/purpose-built for Telcos/NFV. 
But whatever, I raised this concern during the project application as a member 
of the TC and folks ignored me, so it is what it is I guess.



> We were struck in naming the below commands while aligning with the

> OSC naming specs.

>

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



I think what Dean and Akihiro were suggesting is to use "vnf" as the first 
"word" in the command list and then use space-delimited commands like so:



openstack vnf network service create



Or just leave off the "network" above, because, well, Tacker doesn't create any 
other type of service..., so:



openstack vnf service create



and then



openstack vnf forwardinggraph create



and



openstack vnf service function chain create





but then, you'll hit on the obvious overlap with networking-sfc, which will 
bring in the obvious question of "what's the difference between Tacker's SFC 
and networking-sfc's SFC?" which again should lead folks to question the scope 
of Tacker in relation to other OpenStack projects...



Best,

-jay



__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto: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

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

[Jay Pipes]

On 04/12/2017 03:08 AM, Trinath Somanchi wrote:

Hi OSC team-

While  implementing tacker-cli commands as OSC plugins [1], We are
struck in command naming specifications.

Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the
prefix.


It's not *all* of NFV, though.

This problem, by the way, is an indication that Tacker might have too 
big a scope...and a scope that is very much tailored/purpose-built for 
Telcos/NFV. But whatever, I raised this concern during the project 
application as a member of the TC and folks ignored me, so it is what it 
is I guess.



We were struck in naming the below commands while aligning with the OSC
naming specs.

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.


I think what Dean and Akihiro were suggesting is to use "vnf" as the 
first "word" in the command list and then use space-delimited commands 
like so:


openstack vnf network service create

Or just leave off the "network" above, because, well, Tacker doesn't 
create any other type of service..., so:


openstack vnf service create

and then

openstack vnf forwardinggraph create

and

openstack vnf service function chain create

but then, you'll hit on the obvious overlap with networking-sfc, which 
will bring in the obvious question of "what's the difference between 
Tacker's SFC and networking-sfc's SFC?" which again should lead folks to 
question the scope of Tacker in relation to other OpenStack projects...


Best,
-jay

__
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

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

[Trinath Somanchi]

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  


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 q

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

[Akihiro Motoki]

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

> 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
>  
>
>
>
> 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 <trinath.soman...@nxp.com>*
>
> Mobile: +91 9866235130 <+91%2098662%2035130> | Off: +91 4033504051
> <+91%2040%203350%204051>
>
> [image: cid:image001.png@01D28854.B7934C80]
>
>
>
> *From:* Dean Troyer [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>
> *Subject:* Re: [openstack-dev] [Tacker][OSC] Command naming specs
>
>
>
> On Wed, Apr 12, 2017 at 2:08 AM, Trinath Somanchi <
> 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
>
> __
> 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
>
>
__
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

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

[Trinath Somanchi]

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  


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 | Off: +91 4033504051


From: Dean Troyer [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>
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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Dean Troyer]

On Wed, Apr 12, 2017 at 2:08 AM, Trinath Somanchi 
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
__
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

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

[Trinath Somanchi]

Hi OSC team-

While  implementing tacker-cli commands as OSC plugins [1], We are struck in 
command naming specifications.

Tacker being NFVO+VNFM - an NFV component, we have taken 'nfv' as the prefix.

We were struck in naming the below commands while aligning with the OSC naming 
specs.

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.

We want to know what is best fit options to rename the commands.
Kindly help us in improving the command names.
[1] https://review.openstack.org/#/c/455188
Thanking you.
/ Trinath Somanchi.

Trinath Somanchi.
Hyderabad Software Development Center (HSDC), GSD , DN,
NXP India Pvt Limited, 1st Floor, Block 3, DLF Cyber City, Gachibowli,
Hyderabad, Telangana, 500032, India

Email: trinath.soman...@nxp.com  | Mobile: +91 
9866235130 | Off: +91 4033504051
[cid:image002.png@01D28854.B7934C80]




__
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