<div dir="ltr">Hi Jay,<div><br></div><div>See inline ... <br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 14, 2017 at 12:25 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 04/12/2017 03:08 AM, Trinath Somanchi wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi OSC team-<br>
<br>
While  implementing tacker-cli commands as OSC plugins [1], We are<br>
struck in command naming specifications.<br>
<br>
Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the<br>
prefix.<br>
</blockquote>
<br></span>
It's not *all* of NFV, though.<br></blockquote><div><br></div><div>I agree 'nfv' is an umbrella term and it has significance for other projects as well (like nova). </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.</blockquote><div><br></div><div>Will stay away from this as we have thrashed this 'scope' question enough in the TC discussions :)</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We were struck in naming the below commands while aligning with the OSC<br>
naming specs.<br>
<br>
For the below commands, for readability, we have added ‘-‘ within the<br>
command names.<br>
<br>
Like,<br>
<br>
          network-service,  vnf-forwarding-graph, service-function-chain,<br>
<br>
    network-flow-classifier, network-forwarding-path.<br>
</blockquote>
<br></span>
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:<br>
<br>
openstack vnf network service create<br>
<br>
Or just leave off the "network" above, because, well, Tacker doesn't create any other type of service..., so:<br>
<br>
openstack vnf service create<br></blockquote><div><br></div><div><br></div><div>I like this suggestion. Keyword 'vnf' is the closest to the unit of things orchestrated by Tacker. Building on that we can have,</div><div><br></div><div>openstack vnf create - <i>create a single VNF based on TOSCA template</i></div><div>openstack vnf service create - <i>create a service using a collection of VNFs</i></div><div>openstack vnf graph create - <i>create a forwarding graph using a collection of VNFs</i></div><div>...</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
and then<br>
<br>
openstack vnf forwardinggraph create<br>
<br>
and<br>
<br>
openstack vnf service function chain create<br>
<br>
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...<br></blockquote><div><br></div><div>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.</div><div><br></div><div>- Sridhar</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best,<br>
-jay<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div></div>