| *** amotoki has quit IRC | 00:02 | |
| *** arturt_ has joined #tacker | 00:16 | |
| *** uck has joined #tacker | 00:16 | |
| *** uck has quit IRC | 00:21 | |
| *** sridhar_ram has joined #tacker | 00:33 | |
| *** arturt_ has quit IRC | 01:00 | |
| *** arturt_ has joined #tacker | 01:04 | |
| *** lhcheng has quit IRC | 01:09 | |
| *** arturt_ has quit IRC | 01:14 | |
| *** sridhar_ram has quit IRC | 01:25 | |
| *** arturt_ has joined #tacker | 01:30 | |
| *** prashantD has quit IRC | 01:42 | |
| *** prashantD has joined #tacker | 01:43 | |
| *** Sripriya has quit IRC | 01:46 | |
| *** amotoki has joined #tacker | 01:58 | |
| *** arturt_ has quit IRC | 02:00 | |
| *** arturt_ has joined #tacker | 02:02 | |
| *** amotoki has quit IRC | 02:02 | |
| *** arturt_ has quit IRC | 02:06 | |
| *** arturt_ has joined #tacker | 02:31 | |
| *** arturt_ has quit IRC | 02:51 | |
| *** arturt_ has joined #tacker | 02:55 | |
| *** arturt_ has quit IRC | 03:09 | |
| *** prashantD has quit IRC | 03:25 | |
| *** sridhar_ram has joined #tacker | 03:31 | |
| *** arturt_ has joined #tacker | 03:48 | |
| *** Sripriya has joined #tacker | 03:52 | |
| *** Sripriya has quit IRC | 03:59 | |
| *** Sripriya has joined #tacker | 04:03 | |
| *** Sripriya has quit IRC | 04:10 | |
| *** arturt_ has quit IRC | 04:12 | |
| *** arturt_ has joined #tacker | 04:13 | |
| *** arturt_ has quit IRC | 04:37 | |
| *** amotoki has joined #tacker | 04:41 | |
| *** sridhar_ram has quit IRC | 04:44 | |
| openstackgerrit | dharmendra kushwaha proposed openstack/python-tackerclient: Removing "device" API and CLI from master branch. https://review.openstack.org/279382 | 05:16 |
|---|---|---|
| *** lhcheng has joined #tacker | 06:33 | |
| *** lhcheng_ has joined #tacker | 07:15 | |
| *** amotoki has quit IRC | 07:16 | |
| *** lhcheng has quit IRC | 07:17 | |
| *** amotoki has joined #tacker | 07:24 | |
| *** zeih_ has joined #tacker | 07:29 | |
| *** amotoki has quit IRC | 07:35 | |
| *** amotoki has joined #tacker | 07:39 | |
| *** amotoki has quit IRC | 07:43 | |
| *** lhcheng_ has quit IRC | 07:47 | |
| *** amotoki has joined #tacker | 07:55 | |
| *** mbound has joined #tacker | 08:38 | |
| *** tbh has joined #tacker | 09:01 | |
| *** igordcard has joined #tacker | 09:11 | |
| *** zeih_ has quit IRC | 09:14 | |
| *** zeih_ has joined #tacker | 09:17 | |
| *** zeih_ has quit IRC | 09:22 | |
| *** amotoki has quit IRC | 09:34 | |
| *** igordcard has quit IRC | 09:42 | |
| *** amotoki has joined #tacker | 09:48 | |
| *** amotoki has quit IRC | 09:53 | |
| *** amotoki has joined #tacker | 09:56 | |
| *** amotoki has quit IRC | 10:01 | |
| *** amotoki has joined #tacker | 10:10 | |
| *** amotoki has quit IRC | 10:12 | |
| *** amotoki has joined #tacker | 10:13 | |
| *** zeih_ has joined #tacker | 10:19 | |
| *** zeih_ has quit IRC | 10:29 | |
| *** openstackgerrit has quit IRC | 10:32 | |
| *** openstackgerrit has joined #tacker | 10:33 | |
| *** amotoki has quit IRC | 11:30 | |
| *** slo_ has joined #tacker | 11:40 | |
| *** zeih_ has joined #tacker | 12:57 | |
| *** amotoki has joined #tacker | 13:33 | |
| *** amotoki has quit IRC | 13:43 | |
| *** tbh has quit IRC | 13:45 | |
| *** amotoki has joined #tacker | 13:51 | |
| *** amotoki has quit IRC | 13:52 | |
| *** amotoki has joined #tacker | 13:58 | |
| *** Ravikiran_K has joined #tacker | 14:02 | |
| *** bobh has joined #tacker | 14:12 | |
| *** amotoki has quit IRC | 14:45 | |
| *** amotoki has joined #tacker | 14:48 | |
| *** amotoki has quit IRC | 14:53 | |
| *** mbound has quit IRC | 14:55 | |
| *** amotoki has joined #tacker | 15:09 | |
| *** zeih_ has quit IRC | 15:12 | |
| *** zeih_ has joined #tacker | 16:12 | |
| *** zeih_ has quit IRC | 16:18 | |
| *** Ravikiran_K has quit IRC | 16:53 | |
| *** sridhar_ram has joined #tacker | 16:54 | |
| *** zeih has quit IRC | 16:59 | |
| *** zeih has joined #tacker | 17:13 | |
| *** openstackgerrit has quit IRC | 17:17 | |
| *** openstackgerrit has joined #tacker | 17:18 | |
| *** uck has joined #tacker | 17:19 | |
| *** zeih has quit IRC | 17:19 | |
| *** sridhar_ram has quit IRC | 17:27 | |
| *** amotoki has quit IRC | 17:31 | |
| *** sridhar_ram has joined #tacker | 17:50 | |
| *** prashantD has joined #tacker | 18:03 | |
| *** amotoki has joined #tacker | 18:14 | |
| *** lhcheng has joined #tacker | 18:15 | |
| *** openstack has joined #tacker | 18:27 | |
| *** openstackgerrit has quit IRC | 18:47 | |
| *** openstackgerrit has joined #tacker | 18:48 | |
| *** arturt_ has joined #tacker | 19:24 | |
| *** arturt__ has joined #tacker | 19:27 | |
| *** arturt__ has quit IRC | 19:27 | |
| *** arturt_ has quit IRC | 19:31 | |
| *** prashantD has quit IRC | 19:56 | |
| *** prashantD has joined #tacker | 19:58 | |
| *** sridhar_ram1 has joined #tacker | 20:05 | |
| *** sridhar_ram has quit IRC | 20:07 | |
| *** zeih has joined #tacker | 20:56 | |
| *** dkushwaha has quit IRC | 20:59 | |
| *** gubouvier_ has quit IRC | 21:12 | |
| *** zeih has quit IRC | 21:16 | |
| *** uck_ has joined #tacker | 21:23 | |
| *** uck has quit IRC | 21:23 | |
| *** s3wong has joined #tacker | 21:36 | |
| openstackgerrit | Merged openstack/tacker: Updated from global requirements https://review.openstack.org/279777 | 21:40 |
| *** sridhar_ram1 is now known as sridhar_ram | 21:46 | |
| *** gubouvier has joined #tacker | 21:48 | |
| *** bobh has quit IRC | 22:12 | |
| *** lhcheng has quit IRC | 22:14 | |
| *** lhcheng has joined #tacker | 22:15 | |
| *** zeih has joined #tacker | 22:16 | |
| *** lhcheng has quit IRC | 22:20 | |
| *** zeih has quit IRC | 22:22 | |
| sridhar_ram | s3wong: ping | 22:22 |
| s3wong | sridhar_ram: pong | 22:25 |
| s3wong | :1 | 22:26 |
| sridhar_ram | s3wong: looks we are coming a full circle on tacker -> neutron-sfc :) | 22:26 |
| s3wong | (sorry, was doing 'vi' on the other window) | 22:26 |
| s3wong | sridhar_ram: we did talk about that before | 22:26 |
| sridhar_ram | s3wong: np, just wondering if you've any thoughts on the email I sent on rearranging the tasks.. | 22:27 |
| sridhar_ram | s3wong: Tim seems fine w/ that | 22:27 |
| s3wong | sridhar_ram: nvirt is for flow classifier only, right? | 22:28 |
| s3wong | sridhar_ram: so we still need a driver for SFC there... | 22:28 |
| s3wong | sridhar_ram: ideally ODL SFC integration happens soon and we only do networking-sfc integration | 22:28 |
| sridhar_ram | s3wong: what I proposed is take call the ODL code in tacker into neutron-sfc's ODL driver | 22:29 |
| sridhar_ram | s3wong: that is the order I'm proposing.. | 22:29 |
| s3wong | sridhar_ram: Oh, OK, I see --- that is good | 22:29 |
| s3wong | sridhar_ram: I think we need to start rethinking the abstraction we are operating w.r.t. SFC --- but I think that can be step 2 | 22:30 |
| sridhar_ram | 1) tacker vnffg plugin (Tim, no backend driver), (2) tacker vnffg plugin's neutron-sfc driver and in parallel work w/ neutrin-sfc to bring ODL support | 22:30 |
| sridhar_ram | s3wong: rethinking the abstraction is a whole can of worm that need to reopen.. I will we can avoid that for this initial version of tacker vnffg | 22:31 |
| s3wong | sridhar_ram: that is a good initial stop gap solution | 22:32 |
| s3wong | sridhar_ram: as networking-sfc member we love to have ODL as a driver | 22:32 |
| sridhar_ram | btw, just to be clear .. what you mean by "abstraction" here ? | 22:32 |
| s3wong | sridhar_ram: and as Tacker team member, I think we don't want to see ODL hooking up with us directly | 22:33 |
| sridhar_ram | yeah, lets short circuit and do the right way ... even if it means we need to delay a bit for OPNFV teams | 22:33 |
| s3wong | sridhar_ram: by 'abstraction' --- if our APIs are operating on Neutron constructs like Neutron ports, network, subnets...etc, then we aren't providing any value add on top of networking-sfc | 22:33 |
| s3wong | sridhar_ram: a good example for what Tacker can operate on where networking-sfc can't is what we talked about during the midcycle | 22:34 |
| s3wong | sridhar_ram: if Tacker consumes 'abstract service type' | 22:35 |
| s3wong | sridhar_ram: what do we suppose VNFFG is being used in Tacker? | 22:35 |
| sridhar_ram | First, Tacker users will never operate at port level.. the unit of a chain / graph is the VNF itself | 22:36 |
| s3wong | sridhar_ram: what about the ingress point and egress point of the chain/graph? | 22:37 |
| sridhar_ram | API / descriptor to tacker will say .. chain LB & VideoOptimizer VNFs and match these flow / ACL rules | 22:37 |
| s3wong | from network to network, from VNF to VNF? | 22:37 |
| sridhar_ram | ah, I see the confusion.. you can to see through these APIs the eventual VNFFG descriptor.. | 22:38 |
| sridhar_ram | VNFD will have "External Connection Points" .. this is the cue for the TOSCA orchestrator to figure out the neutron ports and use it in the underlying neutron-sfc API calls | 22:39 |
| s3wong | sridhar_ram: I am interested in how it is used. For networking-sfc, it is when a bunch of VMs are already spawned with Neutron ports as connection points, which also means they already have network positions | 22:39 |
| s3wong | sridhar_ram: so literally, when you invoke networking-sfc APIs, you are virtually doing flow-programming via Neutron | 22:40 |
| s3wong | sridhar_ram: what are we doing with VNFFG in Tacker? Deployment? | 22:40 |
| sridhar_ram | We are doing end-to-end orchestration in Tacker .. we are going to handle the "lifecycle" of the VMs, the chains and flow rules over the life of the service... | 22:42 |
| sridhar_ram | we are all thinking these chains as static... but there is a lifecycle to those chains as well.. it will grow, shrink and get hairpinned due to a disaster or load | 22:43 |
| sridhar_ram | it need to use some low-level APIs when chain grows, shrink or redirected to another site | 22:44 |
| sridhar_ram | that is the scope of Tacker.. | 22:44 |
| sridhar_ram | we need low level flow programming to achieve .. but not directly but through neutron-sfc | 22:44 |
| sridhar_ram | if you just look it like the traditional NAT, FW, LB it might look redundant | 22:45 |
| sridhar_ram | let me ask you ... what in your view tacker's VNFFG shd look like ? | 22:47 |
| s3wong | sridhar_ram: does it need to expose low-level APIs for Tacker users to set match rules with something like IP ECN? | 22:48 |
| s3wong | sridhar_ram: for me, it is to show the construction of my FG based on some match criteria | 22:49 |
| sridhar_ram | we don't know at this point the exhaustive list of "match rules" that is applicable for a given network service from an operator... | 22:49 |
| s3wong | sridhar_ram: what Tacker can certainly do which networking-sfc (or anything in Neutron) cannot do is to define a graph on a set of services that may or may not be spawned yet | 22:50 |
| sridhar_ram | we have two options : start with a small set of match rules and grow based on operator input.. or start with the big list from an established SDN controller | 22:50 |
| s3wong | sridhar_ram: networking-sfc has no knowledge of what SFs are being chained together | 22:51 |
| s3wong | sridhar_ram: it is just a set of port-pairs | 22:51 |
| sridhar_ram | cool.. that is how it should be !! | 22:51 |
| s3wong | sridhar_ram: Tacker has that knowledge from VNFd | 22:51 |
| sridhar_ram | it shouldn't care or try interpret what is running in the VM | 22:52 |
| sridhar_ram | yes.. that's why tacker vnffg descriptor will have the graph definition in yaml.. that's why any "API" for FG looks a bit odd .. .. | 22:52 |
| sridhar_ram | .. API is just a short term tool, until we define a VNFFG descriptor template | 22:53 |
| s3wong | sridhar_ram: Tacker can even be the selector of which instance matches the graph definition, or the user can directly select the instance | 22:54 |
| sridhar_ram | yes, those are the areas we need to go into in future release.. pre-spawn VNFs and then apply the graph which will pick from a pool of instantiated VNFs | 22:55 |
| sridhar_ram | bottomline.. for the initial release the only value of using tacker API is the "user" need not worry about / operate at neutron port level.. it is codified in the template and tacker will automatically figure out the ports | 22:57 |
| *** lhcheng has joined #tacker | 22:57 | |
| sridhar_ram | it will break away from neutron-sfc more and more in future releases .. | 22:57 |
| sridhar_ram | this is something we need to educate the neutron-sfc team.. | 22:57 |
| s3wong | sridhar_ram: I think they know, and they know we aren't interested in replicating the networking-sfc APIs | 22:58 |
| s3wong | sridhar_ram: obviously we need to show enough goodwill for clear separation on API level for the TC members | 22:58 |
| sridhar_ram | well, I'm not sure what Cathy means different abstractions are mixed up in Tacker vnffg api | 22:58 |
| s3wong | sridhar_ram: well, Cathy wants an intent based APIs/model to invoke networking-sfc | 23:00 |
| *** gubouvier_ has joined #tacker | 23:01 | |
| *** gubouvier has quit IRC | 23:01 | |
| s3wong | sridhar_ram: being a former GBP team-member, I myself would like to see higher level APIs built on top of these platform level APIs (like networking-sfc) | 23:01 |
| sridhar_ram | Ouch, that's whole different GBP vs Intent vs someother soup I want to stay clear off | 23:01 |
| sridhar_ram | but lets not use Tacker as the playground for Intent or GBP at this point.. | 23:02 |
| sridhar_ram | those are contentious areas will lot of opinions... | 23:02 |
| sridhar_ram | let that play out aware from Tacker and directly on top of neutron-sfc... | 23:03 |
| sridhar_ram | s/aware/away/ | 23:03 |
| s3wong | sridhar_ram: I think we are very tied up with standard based interfaces, so Tacker will likely not become a high-level construct model | 23:03 |
| s3wong | sridhar_ram: for chain definition, we are providing something of different level of abstraction (service-type / instance vs port-pairs) | 23:04 |
| s3wong | sridhar_ram: but for flow classifier, we are basically a direct pipe-through to networking-sfc | 23:05 |
| sridhar_ram | true and I understand the sentiments much better now... | 23:05 |
| sridhar_ram | but I don't see any "higher level" abstraction to describe match rules ... | 23:05 |
| s3wong | sridhar_ram: mestery raised the point of API conflict and direct link to SDN controller (ODL) | 23:06 |
| sridhar_ram | but the value will be when we introduce things like AutoScaling the flow rules need to be automatically adjusted.. | 23:06 |
| sridhar_ram | that's when lifecycle comes in | 23:06 |
| s3wong | sridhar_ram: I think your proposal can remove the latter concern, and I hope that is good enough at least for mestery | 23:07 |
| sridhar_ram | I hope so | 23:07 |
| sridhar_ram | I'll draft an email to ML on my proposal.. | 23:07 |
| sridhar_ram | do you know who owns the ball for ODL in networking-sfc ? | 23:08 |
| sridhar_ram | pcarver ? | 23:08 |
| s3wong | no one | 23:08 |
| s3wong | currently the Mitaka cycle concerns on drivers are ONOS and OVN | 23:09 |
| sridhar_ram | I thought OVN doesn't have SFC ? | 23:09 |
| s3wong | I wanted to do ODL driver for the benefit of Tacker, but it seems unlikely given day job obligations | 23:09 |
| s3wong | sridhar_ram: it doesn't, and it would need to be added to ovsdb northbound | 23:10 |
| sridhar_ram | okay.. however you are signed up for tacker sfc neutron-sfc backend ? | 23:10 |
| s3wong | sridhar_ram: sure | 23:10 |
| sridhar_ram | lets get that going full speed.. | 23:11 |
| sridhar_ram | I'll reach out to few folks for neutron-sfc -> ODL | 23:11 |
| sridhar_ram | stepping away.. glad we had this chat | 23:11 |
| sridhar_ram | ttyl | 23:11 |
| s3wong | ttyl | 23:12 |
| *** zeih has joined #tacker | 23:19 | |
| *** zeih has quit IRC | 23:23 | |
| *** santoshk has joined #tacker | 23:41 | |
| *** lhcheng has quit IRC | 23:46 | |
| *** lhcheng has joined #tacker | 23:47 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!