| *** bobh_ has joined #tacker | 00:21 | |
| *** prashantD has joined #tacker | 02:02 | |
| *** prashantD_ has joined #tacker | 02:03 | |
| *** bobh_ has quit IRC | 02:04 | |
| *** prashantD has quit IRC | 02:06 | |
| *** sridhar_ram has joined #tacker | 02:35 | |
| *** sridhar_ram1 has joined #tacker | 02:38 | |
| *** sridhar_ram has quit IRC | 02:40 | |
| *** tbh has joined #tacker | 02:50 | |
| *** prashantD_ has quit IRC | 03:24 | |
| *** prashantD has joined #tacker | 03:25 | |
| *** tbh has quit IRC | 03:28 | |
| openstackgerrit | Sridhar Ramaswamy proposed openstack/python-tackerclient: Cleanup copyright header https://review.openstack.org/297891 | 03:31 |
|---|---|---|
| *** tbh has joined #tacker | 03:38 | |
| *** tbh has quit IRC | 03:57 | |
| *** bobh_ has joined #tacker | 04:05 | |
| *** bobh_ has quit IRC | 04:11 | |
| *** sridhar_ram1 has quit IRC | 04:36 | |
| *** uck has joined #tacker | 04:39 | |
| *** uck has quit IRC | 04:40 | |
| *** Shahid_ has joined #tacker | 04:47 | |
| *** amotoki has joined #tacker | 05:11 | |
| *** amotoki has quit IRC | 05:18 | |
| *** prashantD has quit IRC | 05:34 | |
| *** bobh_ has joined #tacker | 06:07 | |
| *** bobh_ has quit IRC | 06:12 | |
| *** mbound has joined #tacker | 06:32 | |
| *** mbound has quit IRC | 06:32 | |
| *** Shahid_ has quit IRC | 07:15 | |
| *** janki91 has joined #tacker | 07:39 | |
| *** zeih has joined #tacker | 07:52 | |
| *** janki91 has quit IRC | 07:57 | |
| *** Shahid_ has joined #tacker | 08:19 | |
| *** zeih has quit IRC | 08:21 | |
| *** zeih has joined #tacker | 08:33 | |
| *** mbound has joined #tacker | 08:42 | |
| *** mbound has quit IRC | 08:55 | |
| *** mbound has joined #tacker | 09:04 | |
| *** zeih has quit IRC | 09:33 | |
| *** bobh_ has joined #tacker | 10:09 | |
| *** zeih has joined #tacker | 10:12 | |
| *** bobh_ has quit IRC | 10:13 | |
| *** zeih has quit IRC | 10:27 | |
| *** openstackgerrit has quit IRC | 10:48 | |
| *** openstackgerrit has joined #tacker | 10:49 | |
| *** Shahid_ has quit IRC | 10:52 | |
| *** zeih has joined #tacker | 10:54 | |
| *** Shahid_ has joined #tacker | 11:30 | |
| *** zeih has quit IRC | 12:02 | |
| *** bobh_ has joined #tacker | 12:10 | |
| *** zeih has joined #tacker | 12:13 | |
| *** bobh_ has quit IRC | 12:17 | |
| *** bobh_ has joined #tacker | 12:19 | |
| *** bobh_ has quit IRC | 12:25 | |
| *** uck has joined #tacker | 12:37 | |
| *** mbound has quit IRC | 12:40 | |
| *** mbound has joined #tacker | 13:14 | |
| *** mbound_ has joined #tacker | 13:19 | |
| *** mbound has quit IRC | 13:22 | |
| *** mbound_ has quit IRC | 13:59 | |
| *** bobh_ has joined #tacker | 14:03 | |
| *** Shahid_ has quit IRC | 14:14 | |
| *** mbound has joined #tacker | 14:23 | |
| *** uck has quit IRC | 14:32 | |
| *** vishwanathj has joined #tacker | 15:03 | |
| *** sripriya has joined #tacker | 15:44 | |
| *** lhcheng has joined #tacker | 15:48 | |
| *** amotoki has joined #tacker | 15:48 | |
| *** vishnoianil has quit IRC | 15:49 | |
| *** prashantD has joined #tacker | 15:53 | |
| *** zeih has quit IRC | 15:54 | |
| *** uck has joined #tacker | 16:16 | |
| *** vishnoianil has joined #tacker | 16:21 | |
| *** igordcard_ has quit IRC | 16:34 | |
| *** igordcard has joined #tacker | 16:35 | |
| *** igordcard has quit IRC | 16:35 | |
| *** igordcard has joined #tacker | 16:36 | |
| *** igordcard has quit IRC | 16:36 | |
| *** igordcard has joined #tacker | 16:37 | |
| *** igordcard has quit IRC | 16:41 | |
| *** igordcard has joined #tacker | 16:47 | |
| *** vishnoianil has left #tacker | 16:48 | |
| *** igordcard has quit IRC | 16:50 | |
| *** igordcard has joined #tacker | 16:50 | |
| *** sripriya has quit IRC | 16:57 | |
| *** bharath has joined #tacker | 16:58 | |
| *** igordcard has quit IRC | 17:02 | |
| *** bharath has quit IRC | 17:03 | |
| *** zeih has joined #tacker | 17:23 | |
| *** amotoki has quit IRC | 17:23 | |
| *** sridhar_ram has joined #tacker | 17:26 | |
| *** sripriya has joined #tacker | 17:27 | |
| *** deterrak_ has joined #tacker | 17:31 | |
| deterrak_ | what log files should I look at when onboarding a VNF fails? | 17:32 |
| deterrak_ | ? | 17:40 |
| sripriya | deterrak_: you can take a look at tacker.log file to see the error | 17:42 |
| deterrak_ | here is the error that I get. | 17:49 |
| deterrak_ | 2016-04-04 13:17:45.796 WARNING tacker.vm.drivers.heat.heat [-] | 17:49 |
| deterrak_ | is there a heat log file? | 17:49 |
| *** s3wong has joined #tacker | 17:51 | |
| sripriya | deterrak_: i do not see the full error here, can you use a paste link to share the error? | 18:00 |
| sripriya | dkushwaha: ping | 18:02 |
| dkushwaha | sripriya, hi. | 18:05 |
| sripriya | dkushwaha: the comment was for the commit msg title reg: https://review.openstack.org/#/c/298630/ | 18:06 |
| dkushwaha | sripriya, oh, | 18:07 |
| dkushwaha | sripriya, ok, I will fix it | 18:07 |
| sripriya | dkushwaha: can you do a quick respin, it is good to go otherwise. | 18:07 |
| sripriya | dkushwaha: thanks | 18:08 |
| openstackgerrit | dharmendra kushwaha proposed openstack/tacker: Remove unused attach/detach interface method. https://review.openstack.org/298630 | 18:08 |
| dkushwaha | sripriya, I have a query regarding odl. Is odl support flat network? | 18:10 |
| deterrak_ | Isee that the log got truncated... here is the 2nd relevant line: Resource creation is not completed within 50 seconds as creation of Stack fc88c667-8e24-4fa0-94 | 18:14 |
| sripriya | dkushwaha: i'm afraid i dont know the answer, we usually have our odl expert vishnoianil in the channel who could help with your question, i do not see him now :-) | 18:15 |
| dkushwaha | sripriya, Ok, I will ping him, Thanks for your response. :-) | 18:18 |
| sripriya | deterrak_: which release of openstack are your running? | 18:19 |
| deterrak_ | it is a devstack. I've edited local.conf to pull the stable/mitaka git branch. I left the defauls for the openstack components which are milestone-proposed. | 18:23 |
| *** mbound has quit IRC | 18:25 | |
| sripriya | deterrak_: your error implies the stack creation took more than 50 seconds to complete, the default wait time out was increased to 300 seconds before giving up in tacker.conf for stack_retries and stack_retry_wait | 18:26 |
| sripriya | deterrak_: can you verify that | 18:26 |
| sridhar_ram | deterrak_: fyi, the fix sripriya mentioned is available in mitaka .. but not in liberty | 18:38 |
| sridhar_ram | sripriya: I think we shd cherrypick the fix https://review.openstack.org/#/c/251565/ to stable/liberty ? | 18:39 |
| *** uck_ has joined #tacker | 18:47 | |
| *** uck has quit IRC | 18:47 | |
| sripriya | sridhar_ram: agree | 19:11 |
| sripriya | sridhar_ram: i'll take an AI to cherrypick to liberty | 19:14 |
| sridhar_ram | sripriya: thx! | 19:17 |
| *** mbound has joined #tacker | 19:25 | |
| *** zeih has quit IRC | 19:29 | |
| *** mbound has quit IRC | 19:30 | |
| deterrak_ | in /etc/tacker/tacker.conf I modified [servicevm_heat]; stack_retries = 10 --to-- stack_retries = 60. tried to deploy VNF and I get a new error. | 19:36 |
| deterrak_ | File "/opt/stack/tacker/tacker/vm/plugin.py", line 179, in add_device_to_monitor device_dict, action_cb) ### I am not specifying a monitor rule in the vdnf file. | 19:37 |
| *** uck_ has quit IRC | 19:54 | |
| dkushwaha | Hi, I am trying to test tacker with ODL. Can anybody please let me know, how can I integrate to ODL with Tacker. | 19:58 |
| *** trozet has quit IRC | 20:07 | |
| sripriya | deterrak_: can you share your vnfd template? also it will be helpful if you paste the full trace of the error to debug | 20:08 |
| *** uck has joined #tacker | 20:14 | |
| *** trozet has joined #tacker | 20:16 | |
| trozet | dkushwaha: you could use my walkthrough? | 20:17 |
| trozet | sridhar_ram: ping? | 20:17 |
| sridhar_ram | trozet: pong | 20:17 |
| trozet | sridhar_ram: did you happen to see my emails about making the VNFFG extension more vnffg-like ;) ? | 20:18 |
| sridhar_ram | trozet: is this in the thread that anil started ? | 20:18 |
| trozet | sridhar_ram: no I sent it on Friday, for some reason it didn't go to you, so i re-copied you on it today | 20:19 |
| sridhar_ram | dkushwaha: Basic ODL integration involves getting Neutron to use ODL ML2 plugin. I'd suggest you to start with that first | 20:19 |
| trozet | sridhar_ram: but the suggestion I had is we make the VNFFG act more like a real vnffg | 20:19 |
| sridhar_ram | trozet: I haven't seen the email yet.. I took Friday off and was traveling last 3 days | 20:20 |
| * sridhar_ram is searching for that email... | 20:21 | |
| trozet | sridhar_ram: Re: [opnfv-tech-discuss] [SFC] Creating non-linear SFC | 20:22 |
| sridhar_ram | trozet: ah, opnfv filters should've caught it.. | 20:22 |
| trozet | sridhar_ram: VNFFG is really defining a graph, where you can have multiple paths through | 20:22 |
| trozet | sridhar_ram: translating the ETSI VNFFG idea to IETF SFC, its really multiple classification and chains | 20:22 |
| trozet | sridhar_ram: so what I'm thinking is using the TOSCA template definitions for VNFFG and using those as the main input to the VNFFG extension, then the VNFFG extension figures out what classifiers and chains to create to the driver to assemble the VNFFG | 20:23 |
| sridhar_ram | trozet: understood.. found that email thread. I would've missed it.. thanks for the poke | 20:23 |
| trozet | sridhar_ram: i think the extension is better served doing that. It adds some real orchestration value there | 20:25 |
| sridhar_ram | trozet: that would be awesome if we can go directly to VNFFG TOSCA template support and have it map to underlying SFC construct. As I've stated before, that's the ultimate goal.. | 20:25 |
| trozet | sridhar_ram: right its that + being able to define the VNFFG and rendering it below as multiple chains and classifiers to create the full graph | 20:25 |
| dkushwaha | trozet, I didn't get that mail, gould you please forward me | 20:26 |
| trozet | sridhar_ram: going over the TOSCA this morning I had some questions about the way the VNFD was done in Tacker | 20:26 |
| sridhar_ram | trozet: shoot | 20:26 |
| trozet | dkushwaha: https://github.com/trozet/sfc-random/blob/master/tacker_sfc_walkthrough.txt | 20:26 |
| trozet | sridhar_ram: so when I look at the sample vnfd: https://github.com/openstack/tacker/blob/master/devstack/samples/sample-vnfd.yaml | 20:27 |
| dkushwaha | trozet, thanks | 20:27 |
| trozet | sridhar_ram: pkt_in, pkt_out, those aren't defined as real tosca VND attributes are they? | 20:27 |
| sridhar_ram | trozet: no | 20:27 |
| sridhar_ram | trozet: btw.. | 20:27 |
| sridhar_ram | trozet: .. that sample you showed is using a old syntax, we will deprecate that in Newton | 20:28 |
| trozet | sridhar_ram: according to the NS/VNFFG part, I need to grab connection points, then assign them to "virtual links" which are really L2 networks | 20:28 |
| sridhar_ram | trozet: the new TOSCA template sample would look like https://github.com/openstack/tacker/blob/master/devstack/samples/sample-tosca-vnfd.yaml | 20:28 |
| trozet | sridhar_ram: ah! | 20:29 |
| sridhar_ram | trozet: :) | 20:29 |
| trozet | sridhar_ram: this makes a lot more sense with what i just said in ^^^ | 20:29 |
| sridhar_ram | trozet: to provide you some context.. in tacker Mitaka we cut over to use proper TOSCA parser and support portions of TOSCA NFV Profile | 20:30 |
| trozet | sridhar_ram: yeah i was going to ask you how I would reference the VL and CP of a VNF, now i know | 20:30 |
| sridhar_ram | trozet: in fact, we had to "fix up" few things in the TOSCA spec which are not implementation like VDU, VL, CP.. | 20:31 |
| sridhar_ram | trozet: we stayed away from VNFFG portion of the TOSCA template in Mitaka as we wanted to get the basic correct / in place first | 20:31 |
| sridhar_ram | trozet: a new version of TOSCA NFV profile spec is going to come out in few weeks.. with changes suggested by Tacker | 20:32 |
| sripriya | dkushwaha: ping | 20:32 |
| trozet | sridhar_ram: nice | 20:32 |
| trozet | sridhar_ram: this really helps | 20:32 |
| deterrak_ | Traceback (most recent call last): | 20:32 |
| sridhar_ram | now that we have done the, this is a good time to venture into VNFFG :) | 20:32 |
| trozet | sridhar_ram: so then are these changes to the template already reflected in the master code DB? | 20:32 |
| s3wong | sridhar_ram: is there VNFFG definition already for TOSCA? | 20:32 |
| trozet | sridhar_ram: becaues I will need to query VNFM for a VNF's CP and VL | 20:32 |
| s3wong | sridhar_ram: from here http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/csd01/tosca-nfv-v1.0-csd01.pdf , I see a blank page | 20:33 |
| trozet | s3wong: yeah here http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.pdf | 20:33 |
| *** deterrak_ has quit IRC | 20:33 | |
| trozet | s3wong, : yeah it was missing now its added | 20:33 |
| sridhar_ram | trozet: master (and stable/mitaka) has the latest TOSCA parser code.. | 20:33 |
| dkushwaha | sripriya, hello | 20:33 |
| s3wong | trozet: I see | 20:34 |
| sridhar_ram | trozet: s3wong: what you mean by missing ? It was always there... but I couldn't vouch for its "implementability" :) | 20:34 |
| sridhar_ram | s3wong: trozet: we want to do that exercise in Newton | 20:34 |
| trozet | sridhar_ram: it used to be incomplete when you scrolled down to VNFFG section it was empty | 20:35 |
| sripriya | dkushwaha: https://bugs.launchpad.net/tacker/+bug/1551910 it was previously assigned to another dev, you may want to just let the person know that you took the ownership to fix the bug | 20:35 |
| openstack | Launchpad bug 1551910 in tacker "Remove device related abstractmethods attach interface and detach interfaces" [Low,In progress] - Assigned to dharmendra (dharmendra-kushwaha) | 20:35 |
| s3wong | sridhar_ram: see above link --- it was a blank page | 20:35 |
| sridhar_ram | trozet: in short, are you proposing to NOT to expose tacker vnffg-xyz as APIs ... instead just go towards support VNFFG as a TOSCA template only ? | 20:35 |
| s3wong | sridhar_ram: I would imagine the current TOSCA-parser doesn't have support for VNFFG related objects/ types? | 20:36 |
| sridhar_ram | s3wong: no, it doesn't | 20:36 |
| trozet | sridhar_ram: no, I would still like to give users the option to create their own chains via the CLI already proposed, but I will also add the capability to create graphs via TOSCA input | 20:36 |
| trozet | sridhar_ram: i think inputting a graph by hand in CLI is going to be too complicated | 20:37 |
| sridhar_ram | trozet: absolutely, that's a no go | 20:37 |
| s3wong | agree with trozet here --- I think we absolutely still need APIs | 20:37 |
| trozet | i think we can still allow for | 20:37 |
| trozet | tacker chain-create | 20:37 |
| trozet | then tacker vnffg-create (tosca input only) | 20:37 |
| trozet | if you create vnffg I go parse all the VNFs VL's CPs, and build up the graph, then figure out how many chains and classifiers to render down as chain create calls to the driver | 20:38 |
| trozet | that to me provides a lot of value add to the extension | 20:38 |
| sridhar_ram | trozet: I'm fine taking up the VNFFG TOSCA template support .. but we should avoid providing multiple ways of doing the same thing | 20:38 |
| s3wong | trozet: just read couple emails from the OPNFV thread you mentioned above (thanks for copying me at the first email). Seems like ODL SFC doesn't have support for graph | 20:39 |
| trozet | s3wong: yeah but we can do it as individual building block chains | 20:39 |
| s3wong | trozet: so in Tacker VNFFG common plugin code, you would need to manage all the chains | 20:39 |
| trozet | s3wong: exactly | 20:39 |
| s3wong | trozet: as the matter of fact, we would need to do that anyway as networking-sfc doesn't (and won't) have graph support | 20:40 |
| trozet | s3wong: that was my next question.. networking-sfc :) | 20:40 |
| trozet | s3wong: ok cool well ill fix up the spec tonight to account for this and let you guys know when its pushed | 20:41 |
| trozet | s3wong: I think its more work, but it's the right way to do it and adds a lot more value | 20:41 |
| s3wong | trozet: and since for OpenStack, Tacker VNFFG links directly with networking-sfc, at least for the VNFFG implementation for OpenStack, we would need to maintain the graph | 20:41 |
| s3wong | trozet: agreed | 20:41 |
| dkushwaha | sripriya, When i fixed issue, I didn't know that any bug is already logged related to the same. But yes, I should inform. Ok I will take care about it in future | 20:41 |
| s3wong | trozet: also highlights Tacker's value greatly in the context of forwarding graphs | 20:41 |
| sripriya | dkushwaha: thanks | 20:42 |
| sridhar_ram | trozet: if tacker vnffg-create can still create a singe chain.. satisfy the need for what 'tacker chain-create' why do I need to support the later ? | 20:42 |
| sridhar_ram | trozet: a single chain is just a special case of a graph | 20:43 |
| trozet | sridhar_ram: its different, a graph can have multiple branching strategies | 20:43 |
| trozet | sridhar_ram: it gets more complex, so VNFFG would have to break down the graph and figure out the individual chains it needs to create to build the graph | 20:44 |
| sridhar_ram | trozet: agree, that part make sense but ... | 20:44 |
| trozet | sridhar_ram: a user could go build all of those chains individually | 20:44 |
| trozet | sridhar_ram: with just the chain create command | 20:44 |
| sridhar_ram | trozet: .. once you've that why do you need a single chain create API exposed to Tacker user ? | 20:44 |
| s3wong | sridhar_ram: wouldn't a graph be more cumbersome to create than an individual chain? | 20:45 |
| trozet | sridhar_ram: oh, you dont really. I just wanted to keep it as a simple way to create a chain | 20:45 |
| trozet | sridhar_ram: but the value of keeping the single chain create is we validate the VNF exists and grab its neutron ports rather than telling networking-sfc directly to make a chain from neutron ports | 20:45 |
| sridhar_ram | s3wong: my assumption is simple, single chain graph's template will be simple | 20:46 |
| sridhar_ram | trozet: sure, there is value .. for it to be internally used but my concern, again, is exposing two ways of doing the same thing.. | 20:47 |
| sridhar_ram | trozet: this is what I had in mind... | 20:47 |
| * s3wong is still reading the VNFFG TOSCA template spec | 20:47 | |
| sridhar_ram | we will introduce tacker vnffg API in the first release.. wire it to an underlying low-level SFC like networking-sfc or ODL .. | 20:47 |
| sridhar_ram | .. get some feedback and then.. | 20:47 |
| sridhar_ram | .. introduce VNFFG TOSCA template support and .. | 20:48 |
| sridhar_ram | ... deprecate the vnffg-API in favour of TOSCA template | 20:48 |
| trozet | sridhar_ram: so the new vnffg API would then just take the argument --template and remove --chain | 20:49 |
| sridhar_ram | yeap.. we could skip exposing the API and directly do template support.. | 20:49 |
| trozet | sridhar_ram: ok I see your point, but I still run into problems now with the changes to VNFD | 20:50 |
| sridhar_ram | .. there will be some work in fixing up TOSCA VNFFG template to make it usable (based on my experience) | 20:50 |
| trozet | sridhar_ram: because before I assumed I would know VNF ingress and egress from those pkt_in, pkt_out values | 20:50 |
| sridhar_ram | trozet: lets unblock you first .. | 20:50 |
| trozet | sridhar_ram: but now you are using VL and CP :) | 20:50 |
| trozet | sridhar_ram: so I can't make assumptions if someone just says make me a chain with VNF1 and VNF2 | 20:51 |
| trozet | sridhar_ram: assumptions about which ports they want me to use and which are ingress/egress | 20:51 |
| sridhar_ram | trozet: frankly, this is a good problem to have.. | 20:51 |
| trozet | sridhar_ram: hehe | 20:51 |
| trozet | sridhar_ram: which makes me think i should just go implement the tosca template itself | 20:51 |
| sridhar_ram | old template is sooo ad-hoc.. | 20:51 |
| sridhar_ram | here is a suggestion.. | 20:51 |
| * sridhar_ram is looking up something | 20:51 | |
| trozet | sridhar_ram: what I could do is just implement VNFFG tosca, but only support a single chain and not a complex graph as the first iteration | 20:53 |
| s3wong | trozet: we (VNFG side) becomes more dependent on VNFM side --- we need to look up CP -> neutron port mapping, right? | 20:53 |
| trozet | s3wong: yeah | 20:53 |
| trozet | s3wong: and the VL I think | 20:53 |
| sridhar_ram | trozet: yes, that's an option.. | 20:53 |
| sridhar_ram | trozet: can you clarify how you plan to use ingress / egress, pkt_in / pkt_out ? | 20:54 |
| s3wong | trozet: VL maps to a Neutron network? | 20:54 |
| sridhar_ram | trozet: do they go out as metadata to ODL - SFC ? | 20:54 |
| trozet | s3wong: yeah | 20:54 |
| trozet | sridhar_ram: no I need to know the ingress and egress ports of a VNF | 20:54 |
| trozet | sridhar_ram: the beauty of the POC CLI is you just provide a VNF instance | 20:54 |
| trozet | then I go and figure out the neutron ports | 20:55 |
| trozet | once I have those ports, I can go query ODL's topology map | 20:55 |
| trozet | ODL's topo map has the ports in there and which OVS instance they are on | 20:55 |
| trozet | so then I can build the chain | 20:55 |
| s3wong | trozet: how do you know which of an VNF's ports are ingress vs egress for a particular chain? | 20:55 |
| sridhar_ram | does that apply to a broad stroke of VNFs ? I assume it would .. | 20:56 |
| trozet | s3wong: the old sample_vnfd provided a pkt_in, and pkt_out network type | 20:56 |
| trozet | s3wong: so i could leverage that :) | 20:56 |
| sridhar_ram | trozet: for NSH based chaining, can the ingress and egress be the same neutron port ? | 20:56 |
| s3wong | trozet: unidirectional VNFs :-) | 20:56 |
| trozet | sridhar_ram: yup, in the POC its a single port per vnf to keep it simple | 20:56 |
| trozet | sridhar_ram: i actually hack it to use the mgmt_network :) | 20:57 |
| s3wong | trozet: I sort of noticed that in your plugin code too, you just looked up one port :-) | 20:57 |
| trozet | s3wong: dont tell anybody :) | 20:57 |
| trozet | sridhar_ram, s3wong: https://github.com/trozet/sfc-random/blob/master/test-vnfd.yaml | 20:57 |
| s3wong | sridhar_ram: one arm insertion is very common --- networking-sfc asks that you put that one port into both elements of the port-pair | 20:57 |
| sridhar_ram | trozet: so if it is single neutron port, what use for pkt_in & pkt_out then | 20:58 |
| sridhar_ram | s3wong: yeah, I noticed that usage.. | 20:58 |
| trozet | sridhar_ram: well thats how I was going to implement it upstream, because I thought that's what you guys used to define ingress/egress | 20:58 |
| trozet | sridhar_ram: but now that you are using the proper TOSCA definitions...I'm thinking I should as well :) | 20:58 |
| sridhar_ram | trozet: absolutely.. | 20:59 |
| trozet | sridhar_ram: so you think writing it to parse a complex graph is too much for the first iteration of the spec, and save that for a follow up? | 20:59 |
| sridhar_ram | needless to say I bit confused now :) | 20:59 |
| s3wong | trozet, sridhar_ram: we can perhaps do some simple parsing of VNFFG in Tacker; once it stabilizes we can contribute the code back to tosca-parser | 20:59 |
| trozet | sridhar_ram: focus on a single chain defined graph now, with proper TOSCA templates? | 20:59 |
| trozet | s3wong: is tosca-parser not part of Tacker? | 21:00 |
| sridhar_ram | trozet: I'd definitely suggest that approach | 21:00 |
| s3wong | trozet: no | 21:00 |
| sridhar_ram | s3wong: +1 | 21:00 |
| s3wong | trozet: it is another OpenStack project. Tacker is an user | 21:00 |
| trozet | sridhar_ram: makes sense to me, s3wong what do you think? | 21:00 |
| sridhar_ram | trozet: trosca-parser is a library that tacker consumes... | 21:01 |
| s3wong | trozet: +1 | 21:01 |
| trozet | ok | 21:01 |
| sridhar_ram | I've specific question.. if it is a single vNIC / NSH aware .. | 21:01 |
| trozet | sridhar_ram, s3wong: so then how would I parse the TOSCA for vnffg, parse it myself? | 21:01 |
| sridhar_ram | .. do you still need to mark ingress / egress ? | 21:01 |
| trozet | sridhar_ram: I think for networking-sfc you do | 21:02 |
| s3wong | trozet: you need to write the parsing code in Tacker directly | 21:02 |
| trozet | s3wong: you guys used to parse the tosca yourselves right? Anything there I could leverage? | 21:03 |
| sridhar_ram | trozet: how about for ODL ? | 21:03 |
| s3wong | sridhar_ram and bobh_ can correct me if I am wrong --- but I believe we still parse TOSCA elements in Tacker | 21:04 |
| s3wong | trozet: for example, monitoring | 21:04 |
| sridhar_ram | s3wong: yes.. | 21:04 |
| s3wong | trozet: so extend that code to consume VNFFG TOSCA elements / objects in Tacker before sending a clean, fully standard based TOSCA template to tosca-parser | 21:05 |
| sridhar_ram | we can introduce tacker specific node_types in Tacker and then push to tosca-parser .. or the other way around, send the requirement to tosca-parser and have it implement it in the next dot release. For VNFFG support I'd suggest you to explore working with tosca-parser first and use it in Tacker. | 21:06 |
| trozet | sridhar_ram: for ODL you specify a "data plane locator" which tells ODL how to find the VNF, you can specify more than one, but im not sure how you identify ingress/egress | 21:06 |
| trozet | sridhar_ram: I'll ask Brady or you can in Wed. SFC meeting | 21:06 |
| sridhar_ram | trozet: okay.. will wait for an answer. the suggestion to unblock is use a new property in CP similar to the "management: true" | 21:07 |
| trozet | sridhar_ram, s3wong: ok thanks. I'll update the spec either tonight or tmrw and include what we just went over | 21:07 |
| sridhar_ram | trozet: https://github.com/openstack/tacker/blob/master/devstack/samples/sample-tosca-vnfd.yaml#L24 | 21:07 |
| s3wong | sridhar_ram: the logic of building graph is in our side, so tosca-parser would translate stuff into HOT template, and do we need to expose resources to Heat? | 21:08 |
| trozet | sridhar_ram: well if I go with the TOSCA VNFFG i dont need to worry about any of that, becuase a user defines a forwarding path in the TOSCA | 21:08 |
| sridhar_ram | s3wong: tosca-parser and heat-translator are related but separate project | 21:08 |
| trozet | sridhar_ram: which is an ordered list of CPs | 21:08 |
| trozet | sridhar_ram: so I don't have to make any assumptions :) | 21:08 |
| s3wong | sridhar_ram: I see :-) | 21:08 |
| sridhar_ram | trozet: perfect..! | 21:09 |
| trozet | sridhar_ram: ok thanks guys, my daughter is waking up from her nap so I need to go tend to her. I'll let you know when the spec is updated. Thanks for hte input | 21:09 |
| sridhar_ram | trozet: we got to change the scope of your blueprint to orient toward VNFFG template support | 21:09 |
| sridhar_ram | trozet: go grab her... ! ttyl | 21:10 |
| sridhar_ram | good discussion | 21:10 |
| trozet | later :) | 21:10 |
| s3wong | trozet: have fun! Attend to your daughter! | 21:10 |
| sripriya | sridhar_ram: bobh_: are we planning to handle fixed_ips and port_security_enabled properties for neutron port in tosca templates? | 21:31 |
| sridhar_ram | sripriya: yes, those needs to be supported. if not we need to raise bugs to fix them | 21:32 |
| sripriya | sridhar_ram: ok, i will go ahead and raise bugs | 21:32 |
| sridhar_ram | sripriya: thx! | 21:33 |
| sripriya | sridhar_ram: does that also mean we need to provide the fix in heat translator code or should we wire those in Tacker? | 21:33 |
| bobh_ | sridhar_ram: we should be able to add them to the Tacker port definition and they should get copied into the Port object by heat-translator | 21:33 |
| bobh_ | sridhar_ram: emphasis on "should" - let me check the heat-translator code quick | 21:33 |
| sripriya | bobh_: ok | 21:34 |
| bobh_ | sridhar_ram: sripriya: ip_address is already handled so it may be a property of the Port object already | 21:37 |
| bobh_ | sripriya: sridhar_ram: any other properties that are added will be supported automatically by the code | 21:38 |
| sridhar_ram | bobh_: you mean, any other "tosca.network.Network" property, correct | 21:39 |
| sridhar_ram | ? | 21:39 |
| sripriya | bobh_: so i just add the 2 new properties under VL1 section in TOSCA template? | 21:39 |
| bobh_ | sridhar_ram: The heat-translator code will map any property that it finds on the tosca.network.network.Port object into the OS::Neutron::Port | 21:40 |
| sridhar_ram | bobh_: soooo future proof ;-) | 21:41 |
| bobh_ | tosca.network.Network.Port already has an ip_address property that can be used with no changes | 21:41 |
| bobh_ | sridhar_ram: something like that | 21:41 |
| bobh_ | sridhar_ram: I thought I added the mapping for port_security_enabled already? | 21:42 |
| sridhar_ram | bobh_: that's what I thought for static ip-address, this should should be some documentation and sample tosca template work.. still worth adding a functtional gate test | 21:42 |
| * sridhar_ram thinks we need a running list of func gate tests to add at regular clip | 21:42 | |
| bobh_ | we already support mapping anti_spoofing_protection to port_security_enabled | 21:50 |
| sridhar_ram | bobh_: you did, looks you just converting 'anti_spoof_protection' -> 'port_security_enabled' in https://github.com/openstack/tacker/blob/master/tacker/vm/tosca/utils.py#L66 | 21:51 |
| sridhar_ram | bobh_: so it should work.. and again if for any reason it doesn't we need a bug to go after and fix it | 21:52 |
| bobh_ | sridhar_ram: yup | 21:52 |
| bobh_ | sridhar_ram: should probably have a test for that scenario anyway | 21:52 |
| sridhar_ram | what do folks think about have a laundry list of func tests to add ? creating launchpad rfe bug is cumbersome | 21:54 |
| sripriya | sridhar_ram: shouldnt we add anti_spoof_protection for all CPs anyways? | 21:54 |
| *** santoshk has joined #tacker | 21:58 | |
| sripriya | sridhar_ram: we have been creating functional tests rfes on demand per feature, it will be good to create individual rfes for each of the scenarios. whoever is interested can take it up later | 22:00 |
| sridhar_ram | sripriya: that's sure is an option. I was thinking even a simple etherpad to maintain a list to go after | 22:01 |
| sridhar_ram | and call it our in our weekly meeting | 22:01 |
| sripriya | sridhar_ram: sure, we can later create rfes to add those individual cases | 22:02 |
| sripriya | bobh_: port_security_enabled works fine, just verified it | 22:15 |
| bobh_ | sripriya: cool - thanks! | 22:15 |
| sripriya | bobh_: for the fixed_ips , i need to add it under CP1 properties similar to port_security? | 22:15 |
| bobh_ | If you specify ip_address as a property on the CP object it should get mapped to fixed_ips automagically | 22:16 |
| sripriya | bobh_:toscaparser complains as UnKnownFieldError | 22:17 |
| bobh_ | sripriya: let me look | 22:17 |
| bobh_ | tosca.nodes.network.Port should accept ip_address, order, is_default, ip_range_start and ip_range_end as properties | 22:19 |
| bobh_ | tosca.nodes.nfv.CP is derived from tosca.nodes.network.Port and adds the "type" property | 22:19 |
| bobh_ | tosca.nodes.nfv.CP.TAcker is derived from tosca.nodes.nfv.CP and adds the management and anti_spoofing_protection properties | 22:20 |
| bobh_ | sripriya: so if tosca-parser won't accept the tosca.nodes.network.Port properties that's a bug - I may know what the problem is | 22:21 |
| bobh_ | sripriya: can you check the order and is_default properties and see if it has the same complaint? | 22:21 |
| sripriya | bobh_: ok let me check that | 22:22 |
| sripriya | bobh_: works fine for is_default | 22:24 |
| sripriya | bobh_: what does order property signify? | 22:24 |
| bobh_ | sripriya: NIC order | 22:24 |
| bobh_ | sripriya: I think it starts at 0 but I could be wrong | 22:24 |
| sripriya | bobh_: ok | 22:25 |
| sripriya | bobh_: works fine for order as well | 22:25 |
| bobh_ | sripriya: interesting - sounds like a bug, there is an attribute defined for ip_address too - I wonder if the name conflict causes a problem in tosca-parser | 22:28 |
| *** deterrak has quit IRC | 22:32 | |
| *** bobh_ has quit IRC | 22:33 | |
| *** prashantD_ has joined #tacker | 23:28 | |
| *** prashantD has quit IRC | 23:29 | |
| *** bobh_ has joined #tacker | 23:38 | |
| bobh_ | sripriya: ping | 23:56 |
| sripriya | bobh_: pong | 23:57 |
| bobh_ | sripriya: I was just trying the ip_address property in tosca-parser and couldn't get it to fail | 23:57 |
| bobh_ | sripriya: I'm just using tosca-parser and not tacker so that may be the cause | 23:57 |
| sripriya | bobh_: yes, i was giving the fixed_ips instead of ip_address that is why it was throwing the error, once i updated, the template parser went fine however heat translator now complains it needs to be an integer for ip. but tosca parser takes ip addr as string | 23:58 |
| bobh_ | sripriya: interesting - it should be a string - do you have the heat-translator backtrace? | 23:59 |
| sripriya | bobh_: yup, i was just debugging that. give me a moment | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!