Wednesday, 2015-11-25

*** sridhar_ram has quit IRC00:03
*** sridhar_ram has joined #tacker00:04
openstackgerritMerged openstack/tacker: Fixup oslo middleware to use new package name  https://review.openstack.org/24948200:37
*** lhcheng_ has quit IRC00:42
*** lhcheng has joined #tacker00:42
*** sridhar_ram has quit IRC00:44
*** lhcheng has quit IRC00:46
*** sridhar_ram has joined #tacker00:50
*** santoshk has quit IRC00:58
*** santoshkumark has joined #tacker01:02
*** sridhar_ram1 has joined #tacker01:03
santoshkumarkHi s3wong.01:03
s3wongHello01:03
santoshkumarkcan you please take a look on https://review.openstack.org/#/c/247862/01:03
s3wongsantoshkumark: OK01:04
santoshkumarkthankyou...01:04
s3wongNP01:04
*** sridhar_ram has quit IRC01:04
santoshkumarks3wong: once this is done, i will need your help for reviewing  https://review.openstack.org/#/c/246738/01:06
s3wongsantoshkumark: I will put my name on the reviewers list on all of them :-)01:07
santoshkumarkthankyou...01:07
santoshkumarkthere might be merge conflicts , i will resolve once first review request is merged...01:08
santoshkumarkas both are editing same file adding different testcase in both..01:08
*** sridhar_ram1 is now known as sridhar_ram01:08
santoshkumarks3wong: thanks again...01:09
s3wongsantoshkumark: OK01:09
*** santoshkumark has quit IRC01:09
s3wongsantoshkumark: can't merge with merge conflict since Jenkins won't vote +101:09
*** sripriya has quit IRC01:11
*** karimb has quit IRC01:40
*** prashantD has quit IRC01:41
*** prashantD has joined #tacker01:44
*** gongysh__ has joined #tacker01:46
*** bobh has joined #tacker02:05
*** prashantD has quit IRC02:16
*** bobh has quit IRC02:20
*** gongysh__ has quit IRC02:35
*** santoshkumark has joined #tacker02:50
*** sridhar_ram has quit IRC02:54
*** s3wong has quit IRC02:59
*** vishwanathj has quit IRC03:17
*** santoshkumark has quit IRC03:55
*** gongysh__ has joined #tacker05:39
*** amotoki has quit IRC05:49
*** amotoki has joined #tacker06:01
*** amotoki has quit IRC06:10
*** amotoki has joined #tacker06:15
*** lhcheng has joined #tacker06:31
*** tbh has joined #tacker06:32
*** vishwanathj has joined #tacker06:33
*** amotoki has quit IRC06:39
*** arturt has quit IRC06:42
*** lhcheng has quit IRC06:46
*** lhcheng has joined #tacker07:15
*** gperal has joined #tacker08:00
*** KLuka__ has quit IRC08:19
*** lhcheng has quit IRC08:52
*** mbound_ has joined #tacker08:52
*** karimb has joined #tacker08:52
*** sridhar_ram has joined #tacker08:54
*** sridhar_ram has quit IRC08:59
*** igordcard has joined #tacker09:12
*** lhcheng has joined #tacker09:14
*** lhcheng has quit IRC09:19
*** tbh is now known as Guest496810:01
*** Guest4968 has joined #tacker10:02
*** igordcard has quit IRC10:32
*** gongysh__ has quit IRC11:19
*** gongysh_ has quit IRC11:19
*** mbound_ has quit IRC11:20
*** mbound_ has joined #tacker11:53
*** amotoki has joined #tacker11:54
*** gongysh_ has joined #tacker11:55
*** zeih has joined #tacker11:57
*** gongysh_ has quit IRC11:57
*** masterbound has joined #tacker12:07
*** mbound_ has quit IRC12:07
*** gongysh_ has joined #tacker12:10
*** zeih has quit IRC12:18
*** gongysh_ has quit IRC12:25
*** gongysh_ has joined #tacker12:25
*** zeih has joined #tacker12:28
*** gongysh_ has quit IRC12:31
*** zeih has quit IRC12:54
*** masterbound has quit IRC13:02
*** mbound_ has joined #tacker13:03
*** mbound_ has quit IRC13:08
*** gongysh_ has joined #tacker13:11
*** tab has joined #tacker13:27
*** tab is now known as Guest7062613:27
*** mbound_ has joined #tacker13:27
*** gongysh_ has quit IRC13:35
*** gongysh_ has joined #tacker13:45
*** Guest4968 has quit IRC13:57
*** openstackgerrit has quit IRC14:06
*** openstackgerrit has joined #tacker14:07
*** gongysh_ has quit IRC14:43
*** bobh has joined #tacker14:45
*** gongysh_ has joined #tacker14:53
*** gongysh_ has quit IRC15:01
*** dandruta has joined #tacker15:04
*** bobh has quit IRC15:08
*** KLuka_ has joined #tacker15:19
*** bobh has joined #tacker15:20
*** Guest70626 has quit IRC15:35
*** afv has joined #tacker15:36
*** bobh has quit IRC16:18
*** bobh has joined #tacker16:48
*** bobh has quit IRC16:54
*** mbound_ has quit IRC17:09
*** sripriya has joined #tacker17:11
*** amotoki has quit IRC17:15
*** prashantD has joined #tacker17:20
*** prashantD has quit IRC17:32
*** prashantD has joined #tacker17:32
*** gperal has quit IRC17:35
*** sripriya has quit IRC17:43
*** bobh has joined #tacker18:05
*** karimb has quit IRC18:07
*** bobh has quit IRC18:12
*** dandruta has quit IRC18:16
*** prashantD has quit IRC18:30
*** prashantD has joined #tacker18:33
*** bobh has joined #tacker18:45
*** sripriya has joined #tacker18:50
*** bobh has quit IRC18:57
*** sridhar_ram has joined #tacker18:59
sridhar_ramsripriya: can you look at https://review.openstack.org/#/c/245198/ when you get a chance ?19:06
*** bobh has joined #tacker19:09
*** bobh has quit IRC19:10
sripriyasridhar_ram: sure19:17
sridhar_ramsripriya: thanks!19:19
*** santoshkumark has joined #tacker19:31
*** santoshkumark has quit IRC19:41
*** s3wong has joined #tacker19:43
*** santoshk has joined #tacker19:43
sridhar_ramtrozet: radez: ping, for a quick question19:54
trozetsridhar_ram: hi19:54
sridhar_ramtrozet: as I understand, tacker will be available as post-install option in OPNFV B release, that is still the plan ?19:55
trozetsridhar_ram: yep19:55
sridhar_ramtrozet: cool, then is it okay to be a bit "public" about it .. say in some blog posts ?19:56
trozetsridhar_ram: yeah i would just make sure if anyone asks you say its an "experimental SFC feature"19:56
sridhar_ramtrozet: background, a person from openstack foundation is writing a blog / whitepaper on nfv and she want to mention this possibility19:56
trozetsridhar_ram: I think thats fine19:57
sridhar_ramtrozet: sounds good.. I'll guide her to word it appropriately! thanks Tim..19:57
trozetsridhar_ram: thanks for leaving me feedback on the spec btw.  Been sidetracked on something else but going to look at it in a few min19:57
sridhar_ramtrozet: btw, still catching up the nice discussion on opnfv-sfc thread...19:58
sridhar_ramtrozet: np..19:58
trozetsridhar_ram: yeah some good suggestions19:58
sridhar_ramtrozet: 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-sfc19:59
sridhar_ramtrozet: we can have follow on iterations for some of the smarts suggested in the api...19:59
trozetsridhar_ram: yeah, i think being able to deploy chain as type is important though20:00
*** afv has quit IRC20:00
sridhar_ramtrozet: okay.. I plan to read the email thread bit closely.20:01
s3wongtrozet, 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 instantiated20:05
s3wongI think ODL SFC has always had the idea of setting up "SFC" as a abstract construct, and "SFP" for deployment20:06
s3wongthis sounds like creating templates, then deploy --- which is what Heat is good at20: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
trozets3wong: it can be either with ODL SFC, abstract or specific20:08
trozets3wong: and you are right SFC is abstract, SFP is where you define the instance or just say give me a type20:08
s3wongtrozet: the suggestion is chain=dpi,fw,...etc. I wonder if we need to have available abstract types20:09
trozets3wong: well the type is defined in the VNFD20:09
s3wongtrozet: yes. We need to match them when the chain is deployed20:10
s3wongtrozet: at Tacker level it makes sense to allow this level of abstraction20:10
*** bobh has joined #tacker20:11
trozets3wong: right so i figured if someone provides a chain of types, i just go ask VNFM what vnfds do you have with that type20:11
s3wongtrozet: and if we have more than one that satisfy the type? How do we select?20:12
trozets3wong: types would need to be unique20:12
trozets3wong: instead of firewall for instance needs to be cisco.firewall or something20:13
s3wongtrozet: 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 supported20:14
s3wongtrozet: that would be somewhat user unfriendly, I suppose :-)  though very acceptable for first phase20:14
sridhar_ramtrozet: s3wong: I'm catching up on this concept of chain type...20:15
*** bobh has quit IRC20:15
sridhar_ramtrozet: s3wong: .. so bear w/ me..20:15
trozets3wong: yeah thats how its currently done in ODL SFC, the types have to be unique20:15
trozets3wong: but we should make it more flexible in the future20:16
s3wongtrozet: I see... so nothing on capabilities (like by 'fw' I need 'l7fw' vs 'l4fw' vs 'packet filter'20:16
s3wong)20:16
s3wongtrozet: because technically even if user goes 'cisco.firewall', it can mean all kinds of different firewall capabilities :-)20:17
trozets3wong: 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 code20:17
sridhar_ramtrozet: 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_ramtrozet: s3wong: is this understanding correct ?20:17
trozetsridhar_ram: right20:17
sridhar_ramtrozet: then, as you correctly pointed out in the thread, that goes into the realm of NSD / VNF-Forwarding-Graph20:18
s3wongsridhar_ram: from alagalah's last email, he wants "chain of abstract types" which would be passed through from Tacker to ODL SFC20:18
trozetsridhar_ram: yeah NSD is the best way to do it, but I feel like we can also it on the CMD line as i mentioned20:19
s3wongthen when deployment happens, we spin the VNFs and chain them together20:19
sridhar_ramtrozet: s3wong: no, that is not the correct approach.. it violates the ETSI MANO workflow...20:20
s3wongsridhar_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 Neutron20:20
sridhar_ramtrozet: 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
s3wongsridhar_ram: oh, really? How so?20:20
sridhar_ramtrozet: 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_ramtrozet: s3wong: .. and that is inline with the orchestration workflow20:22
trozetsridhar_ram: so it violates ETSI to have SFC orchestration trigger VNFM to create vnfs?20:22
sridhar_ramtrozet: my point is chaining is not the only aspect of orchestrating VNFs ...20:23
sridhar_ramtrozet: we really need NSD "rendering" feature in tacker to do this properly...20:23
trozetsridhar_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 vnfd20:24
sridhar_ramtrozet: that is my I'm suggesting to do this in two steps...20:24
s3wongsridhar_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_ramtrozet: what is not gelling well is the workflow   sfc-create --triggering --> VNFs spawn.. the correct workflow is nsd-instantiation --> vnf spawning + sfc20:25
s3wongsridhar_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_rams3wong: np, btw, chaining abstract types shd be doable... and it is inline with a future VNFFGD catalog20:26
sridhar_ramtrozet: ETSI envisions a "network service orchestrator" to work with VNFM's to spawn VNFs and work with an SDN-like control plane - realize the chain20:29
trozetsridhar_ram: yeah, but thats what im saying right20:30
trozetsridhar_ram: its just instead of NSD its declared on the cmd line20:30
sridhar_ramtrozet: then we need to introduce NSD level cmd line to do that...not SFC cmd line / api20:31
sridhar_ramtrozet: 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_ramtrozet: 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
trozetsridhar_ram: isnt NSD though itself a tosca term not etsi?20:36
sridhar_ramtrozet: NSD is from ETSI.. tosca is just realizing the information models suggested by ETSI20:37
sridhar_ramtrozet: it seems the suggestion is more from user experience point of view...20:38
sridhar_ramtrozet: ... it seems it is convenient to have *one* CLI to do many of these seemingly multi-step process.20:39
sridhar_ramtrozet: that is just an interim inconvenience.20:39
sridhar_ramtrozet: 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_ramtrozet: openstack review / development process works well in smaller iterations...20:41
trozetsridhar_ram: but its not right, its asking VNFM to do it20:41
trozetsridhar_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
trozetsridhar_ram: isnt that the same thing?20:42
sridhar_ramtrozet: well, it is not if we overloading tacker's sfc-create api ..20:44
sridhar_ramtrozet: the way I've mapped is ...20:44
sridhar_ramtrozet: ... tosca vnffgd yaml --> sfc-create api20:44
sridhar_ramtrozet: ... tosca vnfd yaml --> vnf-create api20:45
trozetsridhar_ram: I guess i fail to see the difference, to me NSO == SFC plugin (which probably should be called SFCO)20:45
sridhar_ramtrozet: ... tosca nsd yamll --> sfc-create + vnf-create20:45
trozetsridhar_ram: ah20:45
sridhar_ramtrozet: this needs a diagram / whiteboard :)20:45
trozetsridhar_ram: so you propose a new plugin, to handle NSO?20:46
sridhar_ramtrozet: yep20:46
trozetsridhar_ram: my initial reaction is it seems like overkill to meet a standard paper20:46
trozetsridhar_ram: but maybe im not aware of the other functions of the NSO20:47
sridhar_ramtrozet: 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 operators20:48
trozetsridhar_ram: yeah20:48
trozetsridhar_ram: so maybe add a comment on the spec that the automatic spawning will be handled by another plugin?20:49
sridhar_ramtrozet: .. atleast that is the pitch for Tacker .. to be *the* ETSI MANO Orchestrator...20:49
sridhar_ramtrozet: yes, that would help ... we need to avoid scope creep20:49
sridhar_ramtrozet: .. some amount of it, based on community comments, is okay .. not as big as this...20:50
sridhar_ramtrozet: lets ask the odl-sfc community to stay tuned for future enhancements that will make things to happen in one shot...20:50
sridhar_ramtrozet: .. I want to get there as well!20:50
*** karimb has joined #tacker20:54
*** prashantD_ has joined #tacker21:06
*** arturt has joined #tacker21:07
*** prashantD has quit IRC21:08
*** arturt has quit IRC21:35
*** openstackgerrit has quit IRC21:36
*** openstackgerrit has joined #tacker21:37
*** prashantD_ has quit IRC21:44
*** bobh has joined #tacker21:45
*** arturt_ has joined #tacker21:48
*** bobh has quit IRC21:51
*** mbound_ has joined #tacker22:00
*** mbound_ has quit IRC22:01
*** mbound_ has joined #tacker22:01
*** arturt_ has quit IRC22:01
*** arturt_ has joined #tacker22:05
*** arturt_ has quit IRC22:07
*** bobh has joined #tacker22:09
*** bobh has quit IRC22:12
*** bobh has joined #tacker22:31
*** bobh_ has joined #tacker22:36
*** bobh has quit IRC22:38
*** mbound_ has quit IRC22:58
*** arturt_ has joined #tacker23:41
*** arturt_ has quit IRC23:41
*** santoshk has quit IRC23:57

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!