*** sridhar_ram has quit IRC | 00:03 | |
*** sridhar_ram has joined #tacker | 00:04 | |
openstackgerrit | Merged openstack/tacker: Fixup oslo middleware to use new package name https://review.openstack.org/249482 | 00:37 |
---|---|---|
*** lhcheng_ has quit IRC | 00:42 | |
*** lhcheng has joined #tacker | 00:42 | |
*** sridhar_ram has quit IRC | 00:44 | |
*** lhcheng has quit IRC | 00:46 | |
*** sridhar_ram has joined #tacker | 00:50 | |
*** santoshk has quit IRC | 00:58 | |
*** santoshkumark has joined #tacker | 01:02 | |
*** sridhar_ram1 has joined #tacker | 01:03 | |
santoshkumark | Hi s3wong. | 01:03 |
s3wong | Hello | 01:03 |
santoshkumark | can you please take a look on https://review.openstack.org/#/c/247862/ | 01:03 |
s3wong | santoshkumark: OK | 01:04 |
santoshkumark | thankyou... | 01:04 |
s3wong | NP | 01:04 |
*** sridhar_ram has quit IRC | 01:04 | |
santoshkumark | s3wong: once this is done, i will need your help for reviewing https://review.openstack.org/#/c/246738/ | 01:06 |
s3wong | santoshkumark: I will put my name on the reviewers list on all of them :-) | 01:07 |
santoshkumark | thankyou... | 01:07 |
santoshkumark | there might be merge conflicts , i will resolve once first review request is merged... | 01:08 |
santoshkumark | as both are editing same file adding different testcase in both.. | 01:08 |
*** sridhar_ram1 is now known as sridhar_ram | 01:08 | |
santoshkumark | s3wong: thanks again... | 01:09 |
s3wong | santoshkumark: OK | 01:09 |
*** santoshkumark has quit IRC | 01:09 | |
s3wong | santoshkumark: can't merge with merge conflict since Jenkins won't vote +1 | 01:09 |
*** sripriya has quit IRC | 01:11 | |
*** karimb has quit IRC | 01:40 | |
*** prashantD has quit IRC | 01:41 | |
*** prashantD has joined #tacker | 01:44 | |
*** gongysh__ has joined #tacker | 01:46 | |
*** bobh has joined #tacker | 02:05 | |
*** prashantD has quit IRC | 02:16 | |
*** bobh has quit IRC | 02:20 | |
*** gongysh__ has quit IRC | 02:35 | |
*** santoshkumark has joined #tacker | 02:50 | |
*** sridhar_ram has quit IRC | 02:54 | |
*** s3wong has quit IRC | 02:59 | |
*** vishwanathj has quit IRC | 03:17 | |
*** santoshkumark has quit IRC | 03:55 | |
*** gongysh__ has joined #tacker | 05:39 | |
*** amotoki has quit IRC | 05:49 | |
*** amotoki has joined #tacker | 06:01 | |
*** amotoki has quit IRC | 06:10 | |
*** amotoki has joined #tacker | 06:15 | |
*** lhcheng has joined #tacker | 06:31 | |
*** tbh has joined #tacker | 06:32 | |
*** vishwanathj has joined #tacker | 06:33 | |
*** amotoki has quit IRC | 06:39 | |
*** arturt has quit IRC | 06:42 | |
*** lhcheng has quit IRC | 06:46 | |
*** lhcheng has joined #tacker | 07:15 | |
*** gperal has joined #tacker | 08:00 | |
*** KLuka__ has quit IRC | 08:19 | |
*** lhcheng has quit IRC | 08:52 | |
*** mbound_ has joined #tacker | 08:52 | |
*** karimb has joined #tacker | 08:52 | |
*** sridhar_ram has joined #tacker | 08:54 | |
*** sridhar_ram has quit IRC | 08:59 | |
*** igordcard has joined #tacker | 09:12 | |
*** lhcheng has joined #tacker | 09:14 | |
*** lhcheng has quit IRC | 09:19 | |
*** tbh is now known as Guest4968 | 10:01 | |
*** Guest4968 has joined #tacker | 10:02 | |
*** igordcard has quit IRC | 10:32 | |
*** gongysh__ has quit IRC | 11:19 | |
*** gongysh_ has quit IRC | 11:19 | |
*** mbound_ has quit IRC | 11:20 | |
*** mbound_ has joined #tacker | 11:53 | |
*** amotoki has joined #tacker | 11:54 | |
*** gongysh_ has joined #tacker | 11:55 | |
*** zeih has joined #tacker | 11:57 | |
*** gongysh_ has quit IRC | 11:57 | |
*** masterbound has joined #tacker | 12:07 | |
*** mbound_ has quit IRC | 12:07 | |
*** gongysh_ has joined #tacker | 12:10 | |
*** zeih has quit IRC | 12:18 | |
*** gongysh_ has quit IRC | 12:25 | |
*** gongysh_ has joined #tacker | 12:25 | |
*** zeih has joined #tacker | 12:28 | |
*** gongysh_ has quit IRC | 12:31 | |
*** zeih has quit IRC | 12:54 | |
*** masterbound has quit IRC | 13:02 | |
*** mbound_ has joined #tacker | 13:03 | |
*** mbound_ has quit IRC | 13:08 | |
*** gongysh_ has joined #tacker | 13:11 | |
*** tab has joined #tacker | 13:27 | |
*** tab is now known as Guest70626 | 13:27 | |
*** mbound_ has joined #tacker | 13:27 | |
*** gongysh_ has quit IRC | 13:35 | |
*** gongysh_ has joined #tacker | 13:45 | |
*** Guest4968 has quit IRC | 13:57 | |
*** openstackgerrit has quit IRC | 14:06 | |
*** openstackgerrit has joined #tacker | 14:07 | |
*** gongysh_ has quit IRC | 14:43 | |
*** bobh has joined #tacker | 14:45 | |
*** gongysh_ has joined #tacker | 14:53 | |
*** gongysh_ has quit IRC | 15:01 | |
*** dandruta has joined #tacker | 15:04 | |
*** bobh has quit IRC | 15:08 | |
*** KLuka_ has joined #tacker | 15:19 | |
*** bobh has joined #tacker | 15:20 | |
*** Guest70626 has quit IRC | 15:35 | |
*** afv has joined #tacker | 15:36 | |
*** bobh has quit IRC | 16:18 | |
*** bobh has joined #tacker | 16:48 | |
*** bobh has quit IRC | 16:54 | |
*** mbound_ has quit IRC | 17:09 | |
*** sripriya has joined #tacker | 17:11 | |
*** amotoki has quit IRC | 17:15 | |
*** prashantD has joined #tacker | 17:20 | |
*** prashantD has quit IRC | 17:32 | |
*** prashantD has joined #tacker | 17:32 | |
*** gperal has quit IRC | 17:35 | |
*** sripriya has quit IRC | 17:43 | |
*** bobh has joined #tacker | 18:05 | |
*** karimb has quit IRC | 18:07 | |
*** bobh has quit IRC | 18:12 | |
*** dandruta has quit IRC | 18:16 | |
*** prashantD has quit IRC | 18:30 | |
*** prashantD has joined #tacker | 18:33 | |
*** bobh has joined #tacker | 18:45 | |
*** sripriya has joined #tacker | 18:50 | |
*** bobh has quit IRC | 18:57 | |
*** sridhar_ram has joined #tacker | 18:59 | |
sridhar_ram | sripriya: can you look at https://review.openstack.org/#/c/245198/ when you get a chance ? | 19:06 |
*** bobh has joined #tacker | 19:09 | |
*** bobh has quit IRC | 19:10 | |
sripriya | sridhar_ram: sure | 19:17 |
sridhar_ram | sripriya: thanks! | 19:19 |
*** santoshkumark has joined #tacker | 19:31 | |
*** santoshkumark has quit IRC | 19:41 | |
*** s3wong has joined #tacker | 19:43 | |
*** santoshk has joined #tacker | 19:43 | |
sridhar_ram | trozet: radez: ping, for a quick question | 19:54 |
trozet | sridhar_ram: hi | 19:54 |
sridhar_ram | trozet: as I understand, tacker will be available as post-install option in OPNFV B release, that is still the plan ? | 19:55 |
trozet | sridhar_ram: yep | 19:55 |
sridhar_ram | trozet: cool, then is it okay to be a bit "public" about it .. say in some blog posts ? | 19:56 |
trozet | sridhar_ram: yeah i would just make sure if anyone asks you say its an "experimental SFC feature" | 19:56 |
sridhar_ram | trozet: background, a person from openstack foundation is writing a blog / whitepaper on nfv and she want to mention this possibility | 19:56 |
trozet | sridhar_ram: I think thats fine | 19:57 |
sridhar_ram | trozet: sounds good.. I'll guide her to word it appropriately! thanks Tim.. | 19:57 |
trozet | sridhar_ram: thanks for leaving me feedback on the spec btw. Been sidetracked on something else but going to look at it in a few min | 19:57 |
sridhar_ram | trozet: btw, still catching up the nice discussion on opnfv-sfc thread... | 19:58 |
sridhar_ram | trozet: np.. | 19:58 |
trozet | sridhar_ram: yeah some good suggestions | 19:58 |
sridhar_ram | trozet: my general suggestion / concern - is not to expand the scope too wide. we need to educate the interested folks .. this is just the 0.1 version of tacker-sfc | 19:59 |
sridhar_ram | trozet: we can have follow on iterations for some of the smarts suggested in the api... | 19:59 |
trozet | sridhar_ram: yeah, i think being able to deploy chain as type is important though | 20:00 |
*** afv has quit IRC | 20:00 | |
sridhar_ram | trozet: okay.. I plan to read the email thread bit closely. | 20:01 |
s3wong | trozet, sridhar_ram: I also took a peek at the email thread. At the end of the thread, Keith was suggesting having abstract types as chain formation, and deploy is when the VNFs are instantiated | 20:05 |
s3wong | I think ODL SFC has always had the idea of setting up "SFC" as a abstract construct, and "SFP" for deployment | 20:06 |
s3wong | this sounds like creating templates, then deploy --- which is what Heat is good at | 20:07 |
s3wong | (of course Tacker now sort of sit on top of Heat, so I guess we should be consuming templates as well...) | 20:08 |
trozet | s3wong: it can be either with ODL SFC, abstract or specific | 20:08 |
trozet | s3wong: and you are right SFC is abstract, SFP is where you define the instance or just say give me a type | 20:08 |
s3wong | trozet: the suggestion is chain=dpi,fw,...etc. I wonder if we need to have available abstract types | 20:09 |
trozet | s3wong: well the type is defined in the VNFD | 20:09 |
s3wong | trozet: yes. We need to match them when the chain is deployed | 20:10 |
s3wong | trozet: at Tacker level it makes sense to allow this level of abstraction | 20:10 |
*** bobh has joined #tacker | 20:11 | |
trozet | s3wong: right so i figured if someone provides a chain of types, i just go ask VNFM what vnfds do you have with that type | 20:11 |
s3wong | trozet: and if we have more than one that satisfy the type? How do we select? | 20:12 |
trozet | s3wong: types would need to be unique | 20:12 |
trozet | s3wong: instead of firewall for instance needs to be cisco.firewall or something | 20:13 |
s3wong | trozet: and the selection shouldn't be done until deployment. Though by the time the "types chain" is defined, we should cross check if the vnfd(s) have these types supported | 20:14 |
s3wong | trozet: that would be somewhat user unfriendly, I suppose :-) though very acceptable for first phase | 20:14 |
sridhar_ram | trozet: s3wong: I'm catching up on this concept of chain type... | 20:15 |
*** bobh has quit IRC | 20:15 | |
sridhar_ram | trozet: s3wong: .. so bear w/ me.. | 20:15 |
trozet | s3wong: yeah thats how its currently done in ODL SFC, the types have to be unique | 20:15 |
trozet | s3wong: but we should make it more flexible in the future | 20:16 |
s3wong | trozet: I see... so nothing on capabilities (like by 'fw' I need 'l7fw' vs 'l4fw' vs 'packet filter' | 20:16 |
s3wong | ) | 20:16 |
s3wong | trozet: because technically even if user goes 'cisco.firewall', it can mean all kinds of different firewall capabilities :-) | 20:17 |
trozet | s3wong: yeah, unfortunately the current way ODL SFC is built - there are only 2 types firewall, and nat. You can only use these 2 types unless you go modify the source code | 20:17 |
sridhar_ram | trozet: s3wong: If I understand the suggestion correct, the operators will issue a "sfc-chain-create" API and the expectation is Tacker will spawn the necessary VNFs in the chain and apply the SFC chain / classifier in the spawn'd VNFs ? | 20:17 |
sridhar_ram | trozet: s3wong: is this understanding correct ? | 20:17 |
trozet | sridhar_ram: right | 20:17 |
sridhar_ram | trozet: then, as you correctly pointed out in the thread, that goes into the realm of NSD / VNF-Forwarding-Graph | 20:18 |
s3wong | sridhar_ram: from alagalah's last email, he wants "chain of abstract types" which would be passed through from Tacker to ODL SFC | 20:18 |
trozet | sridhar_ram: yeah NSD is the best way to do it, but I feel like we can also it on the CMD line as i mentioned | 20:19 |
s3wong | then when deployment happens, we spin the VNFs and chain them together | 20:19 |
sridhar_ram | trozet: s3wong: no, that is not the correct approach.. it violates the ETSI MANO workflow... | 20:20 |
s3wong | sridhar_ram, trozet: I like it as it delineates "SFC" and "SFP" portion in different workflows, and allowing us to do the staging while pushing the plumbing to Neutron | 20:20 |
sridhar_ram | trozet: s3wong: keep in mind SFC is one aspect of the wider network service being deployed - configuration / netconf/yang, monitoring, placement logic need to be place... | 20:20 |
s3wong | sridhar_ram: oh, really? How so? | 20:20 |
sridhar_ram | trozet: s3wong: however if we are talking about creating different abstract SFC/SFP types - apriori and then apply that a set of VNFs that's being spawn that a different story... | 20:22 |
sridhar_ram | trozet: s3wong: .. and that is inline with the orchestration workflow | 20:22 |
trozet | sridhar_ram: so it violates ETSI to have SFC orchestration trigger VNFM to create vnfs? | 20:22 |
sridhar_ram | trozet: my point is chaining is not the only aspect of orchestrating VNFs ... | 20:23 |
sridhar_ram | trozet: we really need NSD "rendering" feature in tacker to do this properly... | 20:23 |
trozet | sridhar_ram: yeah, but im saying the call to create the VNF woudl still go through VNFM as if it were a call to VNFM to create a VNF from a vnfd | 20:24 |
sridhar_ram | trozet: that is my I'm suggesting to do this in two steps... | 20:24 |
s3wong | sridhar_ram: but the chaining of abstract types can be done separately from the actual VNF deployment, right? That shouldn't be violating anything? | 20:24 |
sridhar_ram | trozet: what is not gelling well is the workflow sfc-create --triggering --> VNFs spawn.. the correct workflow is nsd-instantiation --> vnf spawning + sfc | 20:25 |
s3wong | sridhar_ram, trozet: anyway, guys, I have a lunch appointment. I will catch up by reading the channel later. Thanks for the discussion! | 20:25 |
sridhar_ram | s3wong: np, btw, chaining abstract types shd be doable... and it is inline with a future VNFFGD catalog | 20:26 |
sridhar_ram | trozet: ETSI envisions a "network service orchestrator" to work with VNFM's to spawn VNFs and work with an SDN-like control plane - realize the chain | 20:29 |
trozet | sridhar_ram: yeah, but thats what im saying right | 20:30 |
trozet | sridhar_ram: its just instead of NSD its declared on the cmd line | 20:30 |
sridhar_ram | trozet: then we need to introduce NSD level cmd line to do that...not SFC cmd line / api | 20:31 |
sridhar_ram | trozet: we can plan to do that in a follow on BP as we need to take care of few other NSD level semantics.. | 20:32 |
sridhar_ram | trozet: a question (from Keith's email) - "Tacker to instantiate an abstract type" .. is this an abstract SFC/SFP type created without the actual VNFs .. ? | 20:33 |
trozet | sridhar_ram: isnt NSD though itself a tosca term not etsi? | 20:36 |
sridhar_ram | trozet: NSD is from ETSI.. tosca is just realizing the information models suggested by ETSI | 20:37 |
sridhar_ram | trozet: it seems the suggestion is more from user experience point of view... | 20:38 |
sridhar_ram | trozet: ... it seems it is convenient to have *one* CLI to do many of these seemingly multi-step process. | 20:39 |
sridhar_ram | trozet: that is just an interim inconvenience. | 20:39 |
sridhar_ram | trozet: we should not expand the scope of SFC work to spawn VNFs... even if it means short term inconvenience to do this in two steps. | 20:40 |
sridhar_ram | trozet: openstack review / development process works well in smaller iterations... | 20:41 |
trozet | sridhar_ram: but its not right, its asking VNFM to do it | 20:41 |
trozet | sridhar_ram: when you mentioned " ETSI envisions a "network service orchestrator" to work with VNFM's to spawn VNFs and work with an SDN-like control plane - realize the chain" | 20:42 |
trozet | sridhar_ram: isnt that the same thing? | 20:42 |
sridhar_ram | trozet: well, it is not if we overloading tacker's sfc-create api .. | 20:44 |
sridhar_ram | trozet: the way I've mapped is ... | 20:44 |
sridhar_ram | trozet: ... tosca vnffgd yaml --> sfc-create api | 20:44 |
sridhar_ram | trozet: ... tosca vnfd yaml --> vnf-create api | 20:45 |
trozet | sridhar_ram: I guess i fail to see the difference, to me NSO == SFC plugin (which probably should be called SFCO) | 20:45 |
sridhar_ram | trozet: ... tosca nsd yamll --> sfc-create + vnf-create | 20:45 |
trozet | sridhar_ram: ah | 20:45 |
sridhar_ram | trozet: this needs a diagram / whiteboard :) | 20:45 |
trozet | sridhar_ram: so you propose a new plugin, to handle NSO? | 20:46 |
sridhar_ram | trozet: yep | 20:46 |
trozet | sridhar_ram: my initial reaction is it seems like overkill to meet a standard paper | 20:46 |
trozet | sridhar_ram: but maybe im not aware of the other functions of the NSO | 20:47 |
sridhar_ram | trozet: true, there are many standard like that.. but here we are herding telco operators to embrace private cloud / cloud computing for NFs .. we need to map the constructs to what gels with telco operators | 20:48 |
trozet | sridhar_ram: yeah | 20:48 |
trozet | sridhar_ram: so maybe add a comment on the spec that the automatic spawning will be handled by another plugin? | 20:49 |
sridhar_ram | trozet: .. atleast that is the pitch for Tacker .. to be *the* ETSI MANO Orchestrator... | 20:49 |
sridhar_ram | trozet: yes, that would help ... we need to avoid scope creep | 20:49 |
sridhar_ram | trozet: .. some amount of it, based on community comments, is okay .. not as big as this... | 20:50 |
sridhar_ram | trozet: lets ask the odl-sfc community to stay tuned for future enhancements that will make things to happen in one shot... | 20:50 |
sridhar_ram | trozet: .. I want to get there as well! | 20:50 |
*** karimb has joined #tacker | 20:54 | |
*** prashantD_ has joined #tacker | 21:06 | |
*** arturt has joined #tacker | 21:07 | |
*** prashantD has quit IRC | 21:08 | |
*** arturt has quit IRC | 21:35 | |
*** openstackgerrit has quit IRC | 21:36 | |
*** openstackgerrit has joined #tacker | 21:37 | |
*** prashantD_ has quit IRC | 21:44 | |
*** bobh has joined #tacker | 21:45 | |
*** arturt_ has joined #tacker | 21:48 | |
*** bobh has quit IRC | 21:51 | |
*** mbound_ has joined #tacker | 22:00 | |
*** mbound_ has quit IRC | 22:01 | |
*** mbound_ has joined #tacker | 22:01 | |
*** arturt_ has quit IRC | 22:01 | |
*** arturt_ has joined #tacker | 22:05 | |
*** arturt_ has quit IRC | 22:07 | |
*** bobh has joined #tacker | 22:09 | |
*** bobh has quit IRC | 22:12 | |
*** bobh has joined #tacker | 22:31 | |
*** bobh_ has joined #tacker | 22:36 | |
*** bobh has quit IRC | 22:38 | |
*** mbound_ has quit IRC | 22:58 | |
*** arturt_ has joined #tacker | 23:41 | |
*** arturt_ has quit IRC | 23:41 | |
*** santoshk has quit IRC | 23:57 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!