Wednesday, 2016-09-07

sripriyabryan_att: ok, that implies the heat service is not setup properly00:01
bryan_attsripriya: OK, let me take that up with the JOID and Apex teams in OPNFV. Some difference apparently in how they install Heat.00:01
sripriyabryan_att:  i suspect it to be with the additional steps required for heat talk to identity service correctly as pointed to earlier00:05
bryan_attwell at least those steps are documented, right? ;-)00:06
sripriyabryan_att: yes00:06
bryan_attanywhere specific?00:07
bryan_att(we are not using Keystone V3)00:07
sripriyabryan_att: i would look into the heat user ‘heat_domain_admin’ being create in the ‘heat’ domain00:11
sripriyabryan_att: do you see that in the users under ‘Identity’ in dashboard?00:12
bryan_attchecking00:13
bryan_atthttps://www.irccloud.com/pastebin/Uagaaglr/00:14
bryan_attno user "heat_domain_admin"00:14
bryan_atthttps://www.irccloud.com/pastebin/gYCOnRrM/00:15
sripriyabryna_att: the user is an internal user created by heat00:16
sripriyabryan_att: ^00:17
sripriyabryan_att: can you confirm from the dashboard?00:17
bryan_attnot sure what you mean - the user list is the same in the dashboard00:17
bryan_attnot sure what an "internal" user is, do you mean a services project user?00:18
sripriyabryan_att: ‘heat_domain_admin’ user is an internal service project user unlike other users00:19
bryan_attOK, it's not in the list of users for the services project (or any other). How is that user created normally (automatically by Heat?)00:19
sripriyabryan_att: as part of heat manual setup , it needs to be setup00:20
bryan_attand does the creation of that user apply when the Keystone V3 API is not used?00:21
bryan_attthe guide  references the "domain" attribute which is not applicable for V2 AFAIK00:21
bryan_attmaybe the user "heat-cfn_heat" (which is in the list) has the same purpose as the "heat_domain_admin" user (and applies to the same purpose in Keystone V2 environments?)00:23
*** uck_ has quit IRC00:23
sripriyabryan_att: yes applies to v2.000:24
*** uck has joined #tacker00:24
sripriyabryan_att: cfn is for the cloud formation and not related to this00:24
bryan_attOK, so if I create the user, and leave off the "domain" attribute maybe it will work?00:25
sripriyabryan_att: no, you will need the domain as well00:28
bryan_attbut the domain is N/A to Keystone V2?00:28
*** uck has quit IRC00:28
bryan_attsripriya: "domain" parameter is N/A  https://www.irccloud.com/pastebin/J412I7LR/00:30
sripriyabryan_att: the heat domain is stil required, however not using the above command as obviously v2.o does not support multiple domain00:33
sripriyabryan_att: if i look up earlier docs from kilo, heat had a custome command to setup the domain , refer http://docs.openstack.org/kilo/install-guide/install/apt/content/heat-install-controller-node.html To install and configure the Orchestration components section 3.b00:34
bryan_attOk I'll check it out00:36
sripriyabryan_att: keystone can talk both v2.0 and v3 on mitaka , can you enable your environment variables with v3 using: export OS_IDENTITY_API_VERSION=300:36
sripriyaand export OS_AUTH_URL=http://10.18.160.13:5000/v300:36
bryan_attOk I'll try that too00:37
sripriyabryan_att: that way you can run the commands specified to setup heat domain , user and roles using the openstack commands itself00:37
*** sripriya has quit IRC00:47
*** gongysh has joined #tacker01:12
*** dkushwaha has quit IRC01:12
gongyshs3wong, hi01:12
s3wonggongysh: sorry --- didn't get a chance over the Labor Day weekend to review your change01:17
s3wonggongysh: will need to check it out later today01:17
gongyshs3wong, you own me a review https://review.openstack.org/#/c/363398/01:18
gongyshhow's your vnffg feature's progress? can I test it now?01:18
s3wonggongysh: yeah, I know --- I also owe trozet a quick look at his modification of my abstract driver01:19
s3wonggongysh: not yet --- end of the week01:19
gongyshs3wong, fine.  come on.01:19
s3wonggongysh: I will post a new patch (hopefully) tonight; then will work with trozet  and diga  on e2e testing01:19
s3wonggongysh: though probably mostly them than me :-)01:20
openstackgerritNguyen Hung Phuong proposed openstack/tacker: Clean imports in code  https://review.openstack.org/35902301:20
*** prashantD_ has joined #tacker01:24
*** prashantD__ has joined #tacker01:28
*** amotoki has joined #tacker01:29
*** prashantD_ has quit IRC01:31
*** amotoki has quit IRC01:33
openstackgerritvishwanath jayaraman proposed openstack/tacker: VNF Scaling event capture: Functional Test  https://review.openstack.org/36643301:35
vishwanathjgongysh hi....FYI, the functional test for https://review.openstack.org/#/c/363946/ will be captured as part of https://review.openstack.org/366433 .... the 366433 patchset builds on KanagarajM functional patchset for scaling --> https://review.openstack.org/#/c/363573/01:37
*** diga has quit IRC01:39
sridhar_ramgongysh: can you pls merge https://review.openstack.org/364964 ?01:40
gongyshsridhar_ram , sure01:41
gongyshsridhar_ram, is the stable/newton created?01:41
sridhar_ramgongysh: yes01:41
sridhar_ramfor python-tackerclient01:41
*** amotoki has joined #tacker01:46
vishwanathjgongysh hi01:50
gongyshvishwanathj, hi01:50
vishwanathjgongysh with the patchset https://review.openstack.org/#/c/366433/ uploaded will the -1 from you for https://review.openstack.org/#/c/363946/ be removed? Or is there anything else that I would need to do to remove the -1...thanks01:51
gongyshvishwanathj, I +4. done.01:54
vishwanathjgongysh thanks ... appreciate it01:54
gongyshvishwanathj,   I still think we should try our best to do feature and companion test (unit and functional) in on shot.01:56
vishwanathjgongysh sounds good .... will go with your suggestion the next time around01:58
openstackgerritMerged openstack/tacker: Logs events for VNF scale operations  https://review.openstack.org/36394601:58
vishwanathjin this particular case, I am leveraging KanagarajM work which is WIP01:59
gongyshvishwanathj, thanks. by the way, I am not able to join the design summit in Spain (budget). it seems we cannot enjoy the coffee or beer together.01:59
vishwanathjgongysh oh man ... why is that?02:00
gongyshvishwanathj, our company just arranges budget for two guys who have topic selected.02:00
vishwanathjgongysh  so its a budget issue ... was looking forward to meeting you at the tacker design sessions .... I will take an extra coffee on behalf of you02:01
*** amotoki has quit IRC02:05
*** s3wong has quit IRC02:06
*** dkushwaha has joined #tacker02:07
gongyshvishwanathj,  extra 10, 2 each days.02:10
*** vishnoianil has quit IRC02:11
*** amotoki has joined #tacker02:20
*** amotoki has quit IRC02:28
vishwanathjgongysh sure02:33
tung_doanvishwanathj: ping02:35
dkushwahasridhar_ram, ping02:36
openstackgerritTung Doan proposed openstack/tacker: Alarm monitor: All in one  https://review.openstack.org/36543502:38
dkushwahasridhar_ram, Regarding your comment in https://review.openstack.org/#/c/319028/ . Your comment is for all part, not only test_wsgi.py . Right?02:41
openstackgerrithyunsik Yang proposed openstack/tacker: portscan driver for VNF application Monitoring  https://review.openstack.org/32940902:41
*** amotoki has joined #tacker02:41
vishwanathjtung_doan ping02:46
tung_doanvishwanathj: it seems like "auth_attr" param is not used in "log" and "log_and_kill" actions.. To be unified, it is fine for me.. I just wonder whether any reason is begind02:46
tung_doan*begind --> behind02:46
vishwanathjtung_doan refer https://github.com/openstack/tacker/blob/master/tacker/vm/plugin.py#L189 ....02:48
*** amotoki has quit IRC02:48
vishwanathjwhere execute_action is being called ....02:48
vishwanathjwhen I tried to use a template that had the execute action as 'log' and 'log_and_kill', there was an error indicating one less parameter being passed02:51
tung_doanok.. I knew that.. good catch. thanks02:52
*** vishwanathj has quit IRC02:54
*** lulei has joined #tacker02:57
sridhar_ramdkushwaha: yes, rather do this for all parts, no just test_wsgi03:03
sridhar_ramdkushwaha: also, abandon this patchset as well03:03
dkushwahasridhar_ram, ok, I will do.03:04
dkushwahasridhar_ram, thanks03:04
gongyshtung_doan, hi03:12
gongyshubuntu@tacker:~/devstack$ /usr/local/bin/aodh-api -d -v --config-file /etc/aodh/aodh.conf & echo $! >/opt/stack/status/stack/aodh-api.pid; fg || echo "aodh-api failed to start" | tee "/opt/stack/status/stack/aodh-api.failure"03:12
gongysh[1] 1720603:12
gongyshusage: aodh-api [-h] [--port PORT] -- [passed options]03:12
gongyshaodh-api: error: unrecognized arguments: -d -v --config-file03:12
gongyshaodh-api failed to start03:12
gongyshubuntu@tacker:~/devstack$ /usr/local/bin/aodh-api -h03:12
gongyshusage: aodh-api [-h] [--port PORT] -- [passed options]03:12
gongyshmy devstack03:12
gongyshtung_doan, have you bumped into this problem?03:12
*** xiayu1 has joined #tacker03:18
*** xiayu has quit IRC03:20
*** janki has joined #tacker03:28
*** janki has quit IRC03:28
*** sripriya has joined #tacker03:36
*** xiayu has joined #tacker03:42
*** janki has joined #tacker03:43
*** links has joined #tacker03:45
*** xiayu1 has quit IRC03:45
*** KanagarajM has joined #tacker03:46
*** vishnoianil has joined #tacker03:51
gongyshsripriya,  https://review.openstack.org/#/c/363398/ please. thanks03:56
gongyshKanagarajM, https://review.openstack.org/#/c/363398/ please thanks.03:57
sripriyagongysh: thanks for fixing the bug, reviewing it now04:00
tung_doangongysh: hi gonggysh, i dont get this error.. mu devstack worked well when i enabled aodh plugin04:15
tung_doandkushwaha: ping04:17
dkushwahatung_doan, hello04:18
tung_doandkushwaha: also, please kindly let me know if you enable aodh plugin in devstack?04:18
dkushwahatung_doan, yes i did it04:18
tung_doandkushwaha: did you try with curl -X POST.. does it work well to respawn?04:19
dkushwahatung_doan, i could not test again yet.04:20
*** amotoki has joined #tacker04:20
dkushwahatung_doan, i will try, and let you04:20
dkushwahatung_doan, let you know04:21
tung_doandkushwaha: ok.... thanks04:21
dkushwahatung_doan, thanks :)04:22
openstackgerritdharmendra kushwaha proposed openstack/tacker: Refactor Tacker unit tests to remove xml support  https://review.openstack.org/36647904:25
*** hparekh has joined #tacker04:26
*** tbh has joined #tacker04:42
openstackgerritJanki Chhatbar proposed openstack/tacker: Deprecate warning for infra_driver and mgmt_driver at server  https://review.openstack.org/36345504:46
*** tbh has quit IRC04:52
*** prashantD_ has joined #tacker05:03
*** prashantD__ has quit IRC05:06
*** prashantD_ has quit IRC05:07
*** neel has joined #tacker05:07
*** sripriya has quit IRC05:12
*** openstackgerrit has quit IRC05:18
*** openstackgerrit has joined #tacker05:19
openstackgerritNguyen Hung Phuong proposed openstack/tacker: Clean imports in code  https://review.openstack.org/35902305:37
*** yifei has quit IRC06:11
openstackgerrithyunsik Yang proposed openstack/tacker: Port scan driver for VNF application Monitoring  https://review.openstack.org/32940906:15
*** yifei has joined #tacker06:20
openstackgerritgongysh proposed openstack/tacker: Fix the monitor bug  https://review.openstack.org/36339806:31
openstackgerritgongysh proposed openstack/tacker: Fix the monitor bug  https://review.openstack.org/36339806:34
*** Ravikiran_K has joined #tacker06:44
openstackgerritgongysh proposed openstack/tacker: Fix the monitor bug  https://review.openstack.org/36339806:46
sridhar_ramjanki: ping06:47
openstackgerritMerged openstack/tacker: Refactor Tacker unit tests to remove xml support  https://review.openstack.org/36647906:47
jankisridhar_ram, pong06:47
sridhar_ramjanki: are you planning to respin https://review.openstack.org/#/c/340838/ ?06:47
jankisridhar_ram, yes. I have included unit testcases for active and inactive vnfs.06:48
jankisridhar_ram, do I need to include fucntional test case for inactive vnf? already have the same for active vnf06:48
sridhar_ramjanki: no unit test is okay for now, as this is a critical piece for VNFFG and it needs to land soon..06:50
sridhar_ramjanki: this is the one pending on mocking heat api ?06:50
jankisridhar_ram, yes it was. figured out how to mock.06:50
jankisridhar_ram, pushing it now.06:51
sridhar_ramjanki: cool06:51
sridhar_ramgongysh: please review ^^^ and help to wrap this up06:51
openstackgerritJanki Chhatbar proposed openstack/tacker: Add VNF resource details to get vnf API  https://review.openstack.org/34083806:52
openstackgerritJanki Chhatbar proposed openstack/tacker: VNFFG  abstract driver  https://review.openstack.org/34756306:52
jankisridhar_ram, gongysh ^^06:52
gongyshgot it06:52
sridhar_ramgongysh: thanks06:52
openstackgerritJanki Chhatbar proposed openstack/tacker: Add VNF resource details to get vnf API  https://review.openstack.org/34083807:00
*** manikanta_tadi has joined #tacker07:00
*** manikanta_tadi has quit IRC07:00
gongyshjanki, see comments on 30 and 31 patchset.07:08
jankigongysh, about the heat API not available, heat api is never actually called and mocked always. so that scenario might not be created07:10
gongyshthen you can unit test the heat driver itself.07:11
jankigongysh, ohk07:13
gongyshsridhar_ram, the monitor test passed with config_drive.07:22
gongyshsridhar_ram, so this verifies we can do this with metadata service and config_drive.07:22
sridhar_ramgongysh: ack, though it still beats me why it used to succeed for sometime before starting to fail..07:24
sridhar_ramgongysh: for e.g., it used to succeed around mid-july .. see https://review.openstack.org/#/c/329527/07:25
gongyshsridhar_ram, but theoritically, config_drive and metadata service are correct way to fix monitor test case problem07:25
sridhar_ramgongysh: understood, but what i'm pointing out is.. without both config_driver: true and neutron router, for some reason user-data seems to have worked ..07:27
sridhar_ramgongysh: around, early Aug this testcase started to fail..07:27
sridhar_ramgongysh: i thought it was due to a race condition inherent in the test case design07:27
gongyshI think maybe the infra team has changed the CI node. if 169.254.169.254 is on the zuul node, our test cases also work.07:28
sridhar_ramgongysh: I see07:29
gongyshsridhar_ram, it is the case that nova-network will put this address on node.07:29
sridhar_ramgongysh: again, to labor this point .. http-ping continues to work fine even without this fix07:29
sridhar_ramgongysh: sorry, i take the back07:29
sridhar_ramgongysh: you provided an explanation earlier for http-ping07:30
gongyshsridhar_ram, yeah07:30
gongyshthat explanation still works.07:30
sridhar_ramcan you try one or two rechecks so that we are convinced this result is consistent ?07:31
jankigongysh, there are no heat specific unit tests so far. Should I create a dir in tests/unit/infra_driver and write 1 in test_heat.py?07:32
gongyshjanki, https://github.com/openstack/tacker/blob/master/tacker/tests/unit/vm/infra_drivers/heat/test_heat.py07:34
jankigongysh, oops..so sorry07:35
gongyshsridhar_ram,  rechecking07:35
openstackgerritdharmendra kushwaha proposed openstack/tacker: Allow vdu (VM) names to be specified as a parameter  https://review.openstack.org/36354907:37
gongyshdkushwaha, hi07:45
gongysh        for server in servers:07:45
gongysh            if 'test-vdu' in server.name:07:45
gongysh                vdu_server = server07:45
gongysh        self.assertIsNotNone(vdu_server)07:45
gongysh        port_list = self.neutronclient().list_ports()['ports']07:45
gongysh        vdu_port = None07:45
gongysh        for port in port_list:07:45
gongysh            if 'test-cp' in port['name']:07:45
gongysh                vdu_port = port07:45
dkushwahagongysh, hello07:45
gongyshcannot we know exactly what is the names of CP and vdu?07:45
dkushwahagongysh, we can check by listing only07:46
gongyshif we can, we can use 'test-cp' == port['name']07:46
dkushwahagongysh, otherwise we first need to get vm id/ port id07:47
gongyshwhat is the exact port['name07:48
gongysh']07:48
gongysh?07:48
gongyshisn't the 'test-cp'?07:48
dkushwahagongysh, yes it is 'test-cp'07:48
gongyshthen we can if 'test-cp' == port['name']:07:49
dkushwahagongysh, ah, sorry for misinterpreting . yes, we can do this07:49
*** mbound has joined #tacker07:51
openstackgerrithyunsik Yang proposed openstack/tacker: Port scan driver for VNF application Monitoring  https://review.openstack.org/32940907:52
dkushwahagongysh, Thanks for addressing this. I will fix it quickly07:53
openstackgerritdharmendra kushwaha proposed openstack/tacker: Allow vdu (VM) names to be specified as a parameter  https://review.openstack.org/36354907:56
*** openstackgerrit has quit IRC08:34
*** openstackgerrit has joined #tacker08:35
gongyshtung_doan,  what's problem with your alram all in one patch?08:51
gongyshtung_doan, I just want to test when you -1 it.08:51
*** diga has joined #tacker08:52
openstackgerritdharmendra kushwaha proposed openstack/python-tackerclient: Add support for multi delete  https://review.openstack.org/34980608:52
*** links has quit IRC08:53
*** janki has quit IRC08:53
*** links has joined #tacker08:55
*** mbound has quit IRC08:56
*** janki has joined #tacker08:57
*** yifei has quit IRC09:22
tung_doangongysh: no worries.. I just change token v2 to token v3 as Janki'suggstion09:31
tung_doangongysh: I need a bit time to modify09:31
tung_doangongysh: thanks for reminding09:34
gongyshKanagarajM, hi09:35
KanagarajMgongysh, hi09:36
gongyshDoes the scale feature in master work?09:36
KanagarajMgongysh, yes09:36
gongyshI want to test it09:36
KanagarajMwe have a function test patch09:36
KanagarajMhttps://review.openstack.org/36357309:37
KanagarajMgongysh, ^^09:37
gongyshKanagarajM, I see only service group resources are generated.09:38
gongyshKanagarajM, the scale.yml's resources are not in heat stack.09:38
jankigongysh, added heat unit test case. Please review at your convinience https://review.openstack.org/#/c/340838/09:39
KanagarajMgongysh, that is nested stack09:39
KanagarajMgongysh, will be part of scaling group09:39
jankisridhar_ram, submitted edited patch. Apologies. Hadn't seen your +2 and comment09:40
gongyshKanagarajM,  does the scale feature need ceilometer?09:40
openstackgerritMerged openstack/tacker: Clean imports in code  https://review.openstack.org/35902309:44
openstackgerritgongysh proposed openstack/tacker: Fix the monitor bug  https://review.openstack.org/36339809:54
*** Ravikiran_K has quit IRC10:08
openstackgerritvenkatamahesh proposed openstack/tacker: [py35] Fix for jenkins-gate-py35 error  https://review.openstack.org/36665610:14
KanagarajMgongysh, no10:19
KanagarajMgongysh, it will be done once alarm monitor driver is in10:19
openstackgerritvenkatamahesh proposed openstack/tacker: Update the sample vnfd template in getting started guide  https://review.openstack.org/36350110:20
*** saju_m has joined #tacker10:25
jankitung_doan, ping10:29
tung_doanjanki: pong.. hi10:30
jankitung_doan, hey. trying alarm patch. Could you please help me out with the curl thing you mentioned earlier10:30
jankitung_doan, VM is not respawning, no logs in ceilometer too10:31
tung_doanjanki: sure..10:31
openstackgerritKanagaraj Manickam proposed openstack/tacker: Devref for vnf scaling feature  https://review.openstack.org/35920610:32
jankitung_doan, what would be the exact syntax for curl?10:32
tung_doanjanki: dkushwaha, gonggysh... fyi.. the reason it took a bit long time to trigger alarm in ceilometer is that the default interval time in ceilometer is set to 600 (10 mins)10:33
tung_doanjanki: dkushwaha, gonggysh: we need edit this interval time to make it reduce10:34
tung_doanjanki: wait for me :)10:34
tung_doanjanki: http://paste.openstack.org/show/566899/10:35
tung_doanjanki: please change your own http10:35
jankitung_doan, thanks :)10:37
tung_doanjanki: please let me know whether it works.. thanks10:37
jankitung_doan, sure will do10:40
tung_doanjanki: but I am changing eith your suggestion with keystone.. it's not ready to test yet... please wait me for a bit time.. I am setting workflow to -110:42
jankitung_doan, I believe you have changed the version in PS 7. I thought "tenant" (instead of "project") in https://review.openstack.org/#/c/365435/7/tacker/vnfm/monitor_drivers/token.py L29 should throw an error. but it didnot10:44
*** saju_m has quit IRC10:51
tung_doanjanki: correct.. keystone v3 should be like that.. but the error is here "token = keystone.auth_ref['token']['id']"10:59
tung_doanjanki: i did not change totally this part10:59
jankitung_doan, no issue. let me know once dome :)11:00
tung_doanjanki: could you elaborate what is better when using keystone v3... with keystone v3, It is somehow to get token11:01
jankitung_doan, let me try with curl and get back. what exact error are you getting?11:01
tung_doan*is somehow --> is somehow difficult to get token11:02
openstackgerritJanki Chhatbar proposed openstack/tacker-horizon: Adds VNFFG support in Tacker-horizon  https://review.openstack.org/34777911:02
tung_doanjanki: thanks11:02
*** saju_m has joined #tacker11:04
jankitung_doan, what is "plku8ie0" at the end of http?11:05
tung_doanjanki: just key... each request will be added a key..11:06
*** amotoki has quit IRC11:06
jankitung_doan, should I have a different one or this works fine?11:06
tung_doanjanki: sure..11:07
tung_doanjanki: thanks11:07
tung_doanjanki: sorry.. i think it still work fine11:08
tung_doanjanki: but in next few days, key will be authenticated so that alarm url is requested only one time11:10
jankitung_doan, ack!11:10
*** mfedosin has joined #tacker11:26
*** gongysh has quit IRC11:26
*** amotoki has joined #tacker11:37
*** amotoki has quit IRC11:50
*** amotoki has joined #tacker11:58
*** bobh has joined #tacker11:59
*** KanagarajM has quit IRC12:03
*** links has quit IRC12:04
*** amotoki has quit IRC12:07
*** KanagarajM has joined #tacker12:07
*** links has joined #tacker12:16
*** bobh has quit IRC12:20
*** bobh has joined #tacker12:21
*** gongysh has joined #tacker12:23
*** bobh has quit IRC12:28
*** bobh has joined #tacker12:28
*** bobh has quit IRC12:33
*** bobh has joined #tacker12:33
*** amotoki has joined #tacker12:33
*** hparekh has quit IRC12:37
*** bobh has quit IRC12:39
*** bobh has joined #tacker12:40
*** KanagarajM has quit IRC12:40
*** diga has quit IRC12:40
*** KanagarajM has joined #tacker12:41
*** tbh has joined #tacker12:44
*** mike_m has quit IRC12:44
*** bobh has quit IRC12:52
*** janki has quit IRC12:54
*** janki has joined #tacker12:58
*** saju_m has quit IRC13:01
*** gongysh has quit IRC13:07
*** vishwanathj has joined #tacker13:11
*** links has quit IRC13:12
*** neel has quit IRC13:13
*** bobh has joined #tacker13:32
*** tbh has quit IRC13:51
*** janki has quit IRC14:03
*** tbh has joined #tacker14:14
*** tbh has quit IRC14:23
*** yifei has joined #tacker14:26
*** dkushwaha__ has joined #tacker14:42
*** tbh has joined #tacker14:46
*** tung_doan has quit IRC14:48
*** mbound has joined #tacker14:54
*** amotoki has quit IRC14:56
*** tbh has quit IRC15:00
*** gongysh has joined #tacker15:04
gongyshsridhar_ram, https://review.openstack.org/#/c/363398/ is ready to be reviewed15:05
*** yifei has quit IRC15:16
*** tamilhce has joined #tacker15:19
tamilhceHi I'm Tamil vanan ,New to tacker15:19
tamilhce anything that needs a fix regarding coding , i am ready to take up15:20
openstackgerritdharmendra kushwaha proposed openstack/python-tackerclient: Remove "else" branch in "create_vnfd" function  https://review.openstack.org/33472015:21
sridhar_ramgongysh: ack, will +215:23
*** KanagarajM has quit IRC15:27
*** tamilhce has quit IRC15:43
*** gongysh has quit IRC15:45
*** tbh has joined #tacker15:46
*** tbh has quit IRC15:53
*** uck has joined #tacker15:53
*** Vijayendra has quit IRC15:57
*** janki has joined #tacker16:04
*** KanagarajM has joined #tacker16:05
*** Vijayendra has joined #tacker16:09
openstackgerritKanagaraj Manickam proposed openstack/tacker: VNF scaling: Functional test  https://review.openstack.org/36357316:19
*** sripriya has joined #tacker16:29
*** uck has quit IRC16:31
*** uck has joined #tacker16:32
*** tbh has joined #tacker16:33
*** bharatht_ has joined #tacker16:33
*** bharatht_ has quit IRC16:33
*** uck has quit IRC16:36
*** uck has joined #tacker16:38
*** mbound has quit IRC16:39
*** LamT_ has joined #tacker16:40
*** KanagarajM has quit IRC16:40
sridhar_ramtrozet: ping16:42
sridhar_ramtrozet: is any *major* changes anticipated for the ffg abstract driver - https://review.openstack.org/#/c/347563 ?16:42
sridhar_ramjanki: ping16:43
jankisridhar_ram: pong16:43
*** uck has quit IRC16:43
sridhar_ramjanki: any reason why your vnf-resources depends on the above abstract driver patchset ?16:43
jankisridhar_ram: it doesnot depend on that patchset16:44
sridhar_ramjanki: well, if you click the parent link in https://review.openstack.org/#/c/340838/ .. you can see16:45
sridhar_ramjanki: that is one reason it hasn't merged even after it has a +A from tbh16:45
sridhar_ramjanki: anyways, i think we are better off merging the abstract driver and move on16:46
jankisridhar_ram: not sure how it got dependent16:46
sridhar_ramsripriya: are you around to take a quick look at https://review.openstack.org/#/c/347563/ and merge ?16:47
sripriyasridhar_ram: yes, looking16:47
sridhar_ramsripriya: i anticipate there might be few fine tuning as other FFG patchsets fall in place16:47
sridhar_ramsripriya: at least we will have this and janki's vnf-resources out of our way16:47
openstackgerritMerged openstack/python-tackerclient: Remove "else" branch in "create_vnfd" function  https://review.openstack.org/33472016:54
sripriyasridhar_ram: done, looks vnf-resources patch was a child of abstract vnffg driver patch,16:55
sridhar_ramsripriya: thanks and yes, meaning to get that unblocked16:56
*** Vijayendra has quit IRC17:00
openstackgerritMerged openstack/tacker: VNFFG  abstract driver  https://review.openstack.org/34756317:00
openstackgerritMerged openstack/tacker: Add VNF resource details to get vnf API  https://review.openstack.org/34083817:00
sripriyasridhar_ram: https://review.openstack.org/#/c/347563/9/tacker/nfvo/drivers/vnffg/abstract_vnffg_driver.py@38 is it supposed to take multiple fc ids?17:01
sripriyasridhar_ram: i see update_chain taking multiple fc ids but not create_chain17:02
sridhar_ramsripriya: i don't think so, perhaps a typo in update method .. again, will let s3wong and trozet confirm17:03
sridhar_ramvishwanathj: is anything pending from your side for audit event horizon changes ? https://review.openstack.org/#/c/349755/17:04
vishwanathjnope17:05
sripriyasridhar_ram: ok17:09
sripriyasridhar_ram: louis f mentioning a port chain can take multiple fc ids for a similar comment by trozet in an earlier patch. we can revisit this patch later.17:10
*** links has joined #tacker17:14
*** tung_doan has joined #tacker17:16
sridhar_ramsripriya: i'm not sure if we would expose that .. looking at https://review.openstack.org/#/c/344522/23/tacker/tests/unit/vm/infra_drivers/heat/data/vnffgd_template.yaml  .. each FP (chain) would be associated with one FC.17:17
trozetsridhar_ram: hi17:18
sridhar_ramtrozet: hi17:18
trozetsridhar_ram: i think for the initial implementation there should only be a single fc_id per chain17:20
trozetsridhar_ram: so it looks like the fc_ids in update_chain should be fc_id17:20
sridhar_ramtrozet: sounds good.. thats what i thought17:20
sridhar_ramtrozet: we can correct as we go...17:21
trozetsridhar_ram: thinking about that some more... if you have a symmetrical chain, you will need 2 classifiers (one for reverse traffic)17:21
trozetsridhar_ram: but iirc when I talked to s3wong we agreed that should be a driver level thing17:21
trozetsridhar_ram: so specifying symmetrical implies that the reverse classifier gets created and associated and the tacker layer doesn't need to know about it17:22
sridhar_ramtrozet: but that shd be implicit, taken care by the underlying driver, correct?17:22
trozetsridhar_ram: exactly17:22
trozetsridhar_ram: you want me to upload a new patch set with the fc_ids fixed?17:22
trozetsridhar_ram: oh it was already merged17:23
sridhar_ramtrozet: yet, time to iterate :)17:23
trozetsridhar_ram: i guess that is OK for now17:23
sridhar_ram*yes17:23
trozetsridhar_ram: if we inherit that class, and override the method, does python complain if the args arent hte exact same?17:24
sridhar_ramtrozet: let's make necessary fixes as we go.. we are cutting too close17:24
sridhar_ramtrozet: .. particularly with your PTO plan next week17:24
trozetsridhar_ram: yeah i dont mind working the evenings to finish this17:24
sridhar_ramtrozet: appreciate your support !17:25
trozetsridhar_ram: great that the patches got merged, let me rebase my patch now17:25
sripriyatrozet: dont be surprized, but yes python wont complain on args if they are not the same as far as i have seen:)17:25
trozetsripriya: ok thats what i thought.  we should fix it, but doesn't block us17:25
sripriyatrozet: yes,17:25
trozetsridhar_ram, sripriya: s3wong said taht he had an update for hte networking-sfc driver, then i was going to help him port it to the openstack_driver17:26
sripriyatrozet: in fact i see the symmetrical attribute being silently ignored in the n-sfc driver imlementation17:26
trozetsripriya^^17:26
trozetsridhar_ram, sripriya: i did not see a new patch from s3wong last night though on https://review.openstack.org/#/c/347568/17:26
sripriyatrozet: ok17:26
trozetsridhar_ram, sripriya: for now i will update what I can on my patch, test it without the driver in a real openstack setup17:27
sridhar_ramjanki: awesome job in taking this vnf-resources work, patiently working through the reviews and finishing it .. it went through 32 revisions !!17:27
trozetsridhar_ram, sripriya: hopefully s3wong gets online or uploads the new patch so I can take it from there17:27
sridhar_ramtrozet: did s3wong take your offer to help him w/ his patchset ?17:27
jankisridhar_ram: yes. that was what I was thinking while submitting. finally it got merged after 32 (ohh :P) patches :)17:28
trozetsridhar_ram: yeah he said he had already finished some changes to it, but had not migrated it to the openstack driver.  The plan was last night he would upload his latest patch set, then I would take it over and migrate it to the openstack_driver17:28
jankisridhar_ram: I learnt a lot through these reviews though.17:28
sridhar_ramjanki: it just proves you are ready for bigger things around here :) Keep it up !!17:29
*** links has quit IRC17:29
jankisridhar_ram: thanks :)17:29
sridhar_ramtrozet: sounds like a plan17:29
trozetsridhar_ram: so my plan is to at least have tested the whole thing before I leave and have the patch out of WIP17:30
trozetsridhar_ram: at that point maybe you or sripriya could help in reviews/bug fixes while I'm gone and co-author17:30
trozetsridhar_ram: because code freeze is sometime next week right?17:30
sridhar_ramtrozet: yes, next Thursday Sept 15..17:31
sridhar_ramtrozet: i'd like to wrap up and land VNFFG patchsets before you are gone by this Friday .. i know this might sound aggressive..17:32
trozetsridhar_ram: will do my best, let me get it out of WIP then need reviews fast17:32
sridhar_ramtrozet: .. but the way our release window is structured we have some room post Sept 15th to push high-severity fixes17:33
trozetsridhar_ram: yeah fixes should be OK right? just not new features17:33
sridhar_ramtrozet: .. it is generally easier to push point fixes even into stable/newton17:33
sridhar_ramtrozet: exactly17:33
trozetsridhar_ram: so it doesnt have to be flawless, but shoudl be functional17:33
trozetsridhar_ram: i need functional testing too, right?17:34
sridhar_ramso, let's line up everything we have by end of Thursday and push things in by Friday17:34
trozetsridhar_ram: so far i only have unit tests17:34
sridhar_ramtrozet: yes, it is preferred to come in w/ func tests.. but push come to shove, we can have a follow on17:34
trozetsridhar_ram: ok thanks17:35
sridhar_ramtrozet: btw, are you testing this with a some off-tree ODL driver ?17:36
trozetsridhar_ram: no i'm not testing it with ODL, just plain networking-sfc17:36
sridhar_ramtrozet: okay.. just checking17:36
sridhar_ramtbh: can you please review https://review.openstack.org/#/c/349755 ?17:36
tbhsridhar_ram, sure17:38
*** janki has quit IRC17:41
sridhar_ramtbh: thanks!17:42
*** mbound has joined #tacker17:52
*** saju_m has joined #tacker17:52
*** sridhar_ram is now known as sridhar_ram_afk17:52
*** s3wong has joined #tacker17:57
openstackgerritTung Doan proposed openstack/tacker: Alarm monitor: All in one  https://review.openstack.org/36543518:06
*** yifei has joined #tacker18:13
*** s3wong has quit IRC18:15
*** vishnoianil has quit IRC18:16
*** yifei has quit IRC18:18
openstackgerritTung Doan proposed openstack/tacker: Alarm monitor: All in one  https://review.openstack.org/36543518:22
*** sridhar_ram_afk is now known as sridhar_ram18:37
tung_doansridhar_ram: ping18:38
sridhar_ramtung_doan: pong18:38
tung_doansridhar_ram: Do you guys think it is necessary to create only one driver for monitoring?18:39
tung_doansridhar_ram: logically, i thin it's not good18:39
*** saju_m has quit IRC18:39
*** uck has joined #tacker18:40
sridhar_ramtung_doan: let's step and see what is an ideal scenario for a monitoring driver developer...18:40
sridhar_ramtung_doan: .. from framework point of view we are intending to support two types of mon drivers..18:41
sridhar_ramtung_doan: .. (1) tacker ---polling --> VNFs + other entities18:41
sridhar_ram.. (2) tacker <---receiving --- events-from VNFs + other entities (ceilometer, opnfv VES, etc)18:42
tung_doansridhar_ram: thanks.. I believe that we should have a sepatate monitoring driver for (ceilometer, monasca,...)18:42
tung_doansridhar_ram: make sense to me.. totally agree18:42
sridhar_ramtung_doan: hang on.. i'm not done yet18:43
sridhar_ramtung_doan: :)18:43
sridhar_ramtung_doan: .. i'm basically thinking out aloud18:43
* sridhar_ram looking up something18:43
tung_doansridhar_ram: :) unserstand18:44
sridhar_ramtung_doan:  looking at https://review.openstack.org/#/c/365435/9/tacker/vnfm/monitor_drivers/alarm_abstract_driver.py and https://github.com/openstack/tacker/blob/master/tacker/vnfm/monitor_drivers/abstract_driver.py ...18:46
sridhar_ramtung_doan: .. what is the difficulty in merging them into one ?18:46
sridhar_ramtung_doan: .. i'm leaning towards a single alarm driver of different "types"18:47
sridhar_ramtung_doan: ... type : { "poll", "alarm", }18:47
sridhar_ramping, http-ping will be of type: poll18:47
sridhar_ramceilometer, monasca, VES, etc will be of type: "alarm"18:47
tung_doansridhar_ram: at the beginning, it will have problem in monitor.py18:48
tung_doansridhar_ram: .. when we merge them18:48
tung_doansridhar_ram: type : { "poll", "alarm", }  -----> agree18:48
sridhar_ramtung_doan: understood, you should not add monitors of type != poll to the hosting device queue18:48
tung_doansridhar_ram: actually i also follow ves in opnfv :)18:48
sridhar_ramtung_doan: cool..18:49
tung_doansridhar_ram: already did as you said18:49
sridhar_ramtung_doan: so, bottomline .. to avoid monitor driver developer confusion .. i think we should go for a *single* abstract monitor interface18:50
sridhar_ramtung_doan: btw, can u explain how "    def call_alarm_url() " method is used ?18:51
*** s3wong has joined #tacker18:52
tung_doansridhar_ram: the workflow is that: before creating vnf, tacker will call monitoring driver to get alarm url... it should be passed to "real" ceilometer or monasca18:53
tung_doan"it" --> alarm url18:54
sridhar_ramtung_doan: couple of things..18:54
sridhar_ramtung_doan: ... you shd create alarms for a vnf ONLY after it successfully goes to ACTIVE state18:55
sridhar_ram.. next, i think we would be better of calling this API "create_alarm()" that returns an opaque low-level driver specific handle back to the plugin18:56
sridhar_ramhandle == "alarm url"18:56
tung_doanbut heat driver needs alarm url to create template.. could you elaberate it?18:57
sridhar_ramtung_doan: ah, i see..18:58
tung_doan before ACTIVE state.. i think it make sense.. in case of monitoring templates... without alarm url, ot does not make sense18:58
*** uck has quit IRC18:59
sridhar_ramtung_doan: okay, i was worried about ceilometer tripping some CPU thresholds in the initial VM bootup (CPU usually spikes and then settles down)19:01
sridhar_ramtung_doan: .. agree, i don't recommend (for now) to move the create_alram_url() .. as we might need to resort to stack-update (do-able, but more effort) after a VNF goes active19:02
tung_doanregarding to the CPU threshold...19:03
tung_doansridhar_ram: we will need to change ceilometer pipeline because the default interval in ceilometer is 600 (10mins).. I worry someonee could be confused19:04
tung_doansridhar_ram: i just wonder if you need a document to explian monitor driver iin tacker?19:05
sridhar_ramtung_doan: can that be passed in as an argument in the create_alarm() call down to ceilometer instead of changing the default ?19:06
sridhar_ramtung_doan: well, tacker-spec is the place where we should've documented all this...19:06
sridhar_ramanother question...19:06
sridhar_ramtung_doan: what is the different between process_alarm() and process_notification() in the abstract driver ?19:06
tung_doansridhar_ram: i mean how to setup env.. becasue i got alot of questions19:07
sridhar_ramtung_doan: oh, sure.. absolute.. include that document as a devref into your patchset itself19:07
sridhar_ram*absolutely19:07
tung_doan"passed in as an argument in the create_alarm() call down to ceilometer instead of changing the default"... could you elaborate it?19:08
*** vishnoianil has joined #tacker19:09
sridhar_ramtung_doan: sure, my understanding is 600s is the default in ceilometer .. can that be changed on a per-alarm basis to something shorter ?19:09
tung_doan"different between process_alarm() and process_notification()" ---> actually it is still undevelopement and I will have to remove or develop it19:09
sridhar_ramtung_doan: okay.. basically i'm curious about https://review.openstack.org/#/c/365435/9/tacker/alarm_receiver.py19:11
sridhar_ramtung_doan: .. how it fits into the alarm driver19:11
tung_doansridhar_ram: sure. just change period in alarm configuration19:11
sridhar_ramin ceilometer.conf ?19:12
tung_doanah, regarding to alarm_receiver.. i need to change a better name19:12
tung_doani mean in tosca template... for pipeline, once we enable ceilometer plugin we can change in /etc/ceilometer/pipeline.yaml19:14
tung_doansridhar_ram: did you get the main idea of alarm_receiver.py?19:15
sridhar_ramtung_doan: okay.. i clearly need to spend more time reviewing your patchset :)19:16
sridhar_ramtung_doan: my understanding is, this code will receive the  ceilometer callback invocation ?19:16
*** foutatoro has joined #tacker19:16
tung_doansridhar_ram: i think so.. franky, thanks all guys for spending time with my spec :)19:16
sridhar_ramtung_doan: back to the original question.. can you explore merging alarm and the original monitor absract drivers into one common one ?19:17
tung_doansridhar_ram: just need a bit change in monitor.py .. will do19:18
sridhar_ramtung_doan: thanks19:18
sridhar_ramtung_doan: also, if you can add that document explaining how to use this feature, it will help all of us (including me) to test this better and provide better comments19:18
tung_doanok.. maybe this weekend will fine for me.. i am trying to finish my code this week19:19
foutatoroHi all I would like to know if you have a wiki that describes how to build service function chaining using tacker and opendaylight-sfc-driver ?19:19
*** tbh has quit IRC19:19
tung_doanif you guys need some guides to test.. will finish ASAP19:22
foutatoroany suggestion guys ?19:28
sridhar_ramfoutatoro: we don't have a write up yet.. parts of it are still in progress and will fall in place soon (in next few weeks)19:30
*** tung_doan has quit IRC19:31
*** sripriya has quit IRC19:33
foutatorosridhar_ram: thanks. I've successfully create SFC in real server using opendaylight boron. Is it possible to test now tacker with the sfc-driver ?19:36
*** sripriya has joined #tacker19:41
openstackgerritTim Rozet proposed openstack/tacker: [WIP] Implements VNFFG into NFVO  https://review.openstack.org/34452219:57
sridhar_ramfoutatoro: we are taking tacker --> neutron-sfc --> ODL to configure ODL-SFC..19:57
s3wongfoutatoro: you need to wait until ODL networking-sfc driver to be available...19:57
sridhar_ramfoutatoro: .. we are currently waiting for https://review.openstack.org/#/c/337948/ to wrap up19:59
sridhar_ramvishnoianil: is working on that piece20:00
trozets3wong: hi20:00
s3wongsridhar_ram: yeah, I was looking for that review link :-)20:00
s3wongtrozet: pong20:00
trozets3wong: are you planning to upload your new patch set soon?20:01
s3wongtrozet: I plan to update patch sometime this afternoon20:01
trozets3wong: ok cool20:01
s3wongtrozet: last night I sinked all my time on day job stuff --- worked until 2am, in fact20:01
trozets3wong: that sucks :(20:01
s3wongtrozet: yeah, unfortunately --- the two deadlines are pretty much around the same time20:02
vishnoianilsridhar_ram, s3wong foutatoro i will push a v2 version of the driver sometime next week20:02
foutatoroThanks for these information20:03
*** openstackgerrit has quit IRC20:04
*** mbound has quit IRC20:04
*** openstackgerrit has joined #tacker20:05
sridhar_ramvishnoianil: sounds good.. thanks20:27
*** gongysh has joined #tacker20:49
gongyshsripriya, hi20:50
*** vishnoianil has quit IRC20:50
*** sripriya has quit IRC20:50
*** avishnoi has joined #tacker20:50
*** vishwana_ has joined #tacker20:51
s3wonggongysh: still up?  :-)20:51
*** sripriya has joined #tacker20:51
gongyshs3wong, waked up.20:51
trozetsripriya: ping20:51
sripriyatrozet: pong20:51
s3wongtrozet: is there any reason why your patch is still WIP?20:51
gongyshs3wong , https://review.openstack.org/#/c/363398/ please20:51
trozetsripriya: ran into something that I could use your input on20:52
s3wonggongysh: sure --- looking at it now20:52
*** vishwanathj has quit IRC20:52
trozetsripriya: so i have written the tosca validator in the openstack driver, passes unit tests just fine20:52
trozetsripriya: but now I go to invoke it to validate VNFFGD, and I realize in the nfvo_plugin, I don't know what vim driver to use :)20:53
trozetsripriya: at this point I don't have any VNFs, so i cant use those to figure out the driver type20:53
trozets3wong: I just wanted to finish the TOSCA validation before i remove the WIP (working on it now)20:53
sripriyatrozet: validation of template should be handled by the plugin itself and not by the driver20:54
trozetsripriya: ok i had that thought right after i finished it :)20:55
openstackgerritDoug Hellmann proposed openstack/python-tackerclient: Update reno for stable/newton  https://review.openstack.org/36496520:55
sripriyatrozet: i’m doing the same for vnfd templates now :)20:55
trozetsripriya: why dont we just use a common method?20:55
trozetsripriya: i just kind of made a single method that works for both20:55
sripriyatrozet; i have a WIP patch to group the common tosca validations into a common module which any resource can use20:56
sripriyatrozet: hopefully i can give some justice to it before the deadline20:56
trozetsripriya: yeah i saw there is some deprecated/vnf specific stuff20:56
trozetsripriya: so i just did this:20:56
trozethttps://paste.fedoraproject.org/423635/20:57
trozetsripriya: i guess for now i will just use my stuff so i dont depend on your common patch, then later we should converge20:57
sripriyatrozet: does your code take the vnffd template as a string?20:58
trozetsripriya: no20:58
trozetsripriya: i saw that stuff leftover in vnfm, but i don't think its supported for vnffg20:59
sripriyatrozet: what type of data is template on L9 in your paste link20:59
trozetsripriya: its just the <template> part of the content stored as {'vnfd/vnffgd': <template>}21:00
sripriyatrozet:<template> is a dict?21:01
trozetsripriya: yah21:01
sripriyatrozet: ok cool,21:03
trozetsripriya: i have these unit tests, which pass https://paste.fedoraproject.org/423637/raw/21:03
openstackgerritMerged openstack/tacker: Fix the monitor bug  https://review.openstack.org/36339821:03
*** mbound has joined #tacker21:05
sripriyatrozet: not sure why you are converting to dict again your validate when you already have yaml input as dict21:05
trozetsripriya: in the tests or the method?21:06
sripriyatrozet: in the method21:06
sripriyatrozet: and in your tests, you are adding the template to [vnfd][ attributes][‘vnfd’] which is not defined in api extension layer for vnffgd21:07
trozetsripriya: thats just cause they were openstack_driver tests and i knew those vnfds would pass and thought VNFM would move to this "driver"21:08
trozetsripriya: https://paste.fedoraproject.org/423640/21:08
trozetsripriya: i did the load because I saw the load there for vnfd21:08
sripriyatrozet: also, you need to update vnfd as vnffd everywhere as they are two different resources21:09
trozetsripriya: where?21:09
sripriyatrozet: that is exactly we “dont” want to do, take template as string and load it as dict internally,21:09
*** mbound has quit IRC21:10
trozetsripriya: oh that was only there because vnfd template could be a string21:10
sripriyatrozet: references in your test cases21:10
trozetsripriya: ok let me remove that then21:10
trozetsripriya: yeah i will.  Like i said it was just because i knew vnfd ones were correct21:10
trozetsripriya: i'm not so sure the vnffgd is going to pass the tosca validator21:11
sripriyatrozet: in vnffgd (unlike vnfd) we have support now in API and db to store the template as json instead of yaml string, this is easier to work with compared to yaml string21:11
sripriyatrozet: vnfd is goign through some refactoring to follow the same21:12
sripriyatrozet: it is being done in smaller increments so that there is minimal impacts between different releases21:13
trozetsripriya: ok21:13
trozetsripriya: it looks like the yaml load is required, because the object is unicode21:25
gongyshsripriya, https://review.openstack.org/#/c/363483/21:35
*** bobh has quit IRC21:36
*** sripriya has quit IRC21:37
openstackgerritvishwanath jayaraman proposed openstack/tacker: VNF monitoring event capture: Functional test  https://review.openstack.org/36622621:39
*** sripriya has joined #tacker21:40
trozetsridhar_ram: ping?21:40
*** LamT_ has quit IRC21:41
trozetsripriya: ping?21:42
sripriyatrozet: how are you sending the template to the vnfd api?21:42
sripriyagongysh: will take a look21:43
trozetsripriya: oh heh, it uses the _get_template function in the test utils, which reads the file as a string ;)21:44
sripriyatrozet: :-)21:44
trozetsripriya: will fix tht21:44
trozetsripriya: so here is the deal21:44
trozetsripriya: i have the tosca parser running on my template21:44
trozetsripriya: but it turns out tosca parser is too smart :)21:45
trozethttps://paste.fedoraproject.org/423658/raw/21:46
trozetsripriya:^ that fails because the parser actually reads the forwarder VNF<num> and CP<num> and expects them to be in the definition :)21:47
sripriyatrozet: why should the values be part of the definitions?21:49
trozetsripriya: because in a real NS definiton, the VNFs and everything would be in one template21:49
trozetsripriya: i think tacker is working towards that in the future, but for this iteration VNFD/VNFFGD is separate and not under one template def21:49
trozetsripriya: so i think we can either A) require a user to copy the VNFD template into the VNFFGD template, B) automatically look up the VNFD before sending it to tosca parser and include in the parser arg21:51
trozetsridhar_ram:^21:55
sripriyatrozet: so does tosca parser expect us to specify valid forwarder values in the template?21:57
trozetsripriya: correct21:58
trozetsripriya: example: KeyError: 'Node template "VNF3" was not found.'21:58
sripriyatrozet: ah ok21:58
sripriyatrozet: and is it the same for capability as well?21:59
trozetsripriya: yep21:59
trozetKeyError: 'Node template "CP11" was not found.'21:59
sripriyatrozet: looking into heat translator coded21:59
trozetsripriya: it also doesnt like that I am using a non-tosca field "id" to hold the path ID21:59
sripriyacode*21:59
trozetUnknownFieldError: Node template "Forwarding_path1" contains unknown field "id". Refer to the definition to verify valid values.22:00
trozetsripriya: i've got go afk for a few hours, will be back...not sure what to do about this22:00
sripriyatrozet: yes it chokes up if you specify an unknow field, you will have to add that to tacker_nfv_defs.yaml and apply the imports22:00
trozetsripriya: ah ok at least that is a work around22:00
trozetsripriya: but let me know what you think about the VNF/CP issue22:01
sripriyatrozet: sure i need to look into heat translator code to see that22:01
trozetsripriya: just tosca translator right22:02
trozetsripriya: no heat22:02
*** sripriya has quit IRC22:03
*** gongysh has quit IRC22:03
*** mfedosin has quit IRC22:07
openstackgerritvishwanath jayaraman proposed openstack/tacker: VNF Scaling event capture: Functional Test  https://review.openstack.org/36643322:09
*** gongysh has joined #tacker22:27
*** yifei has joined #tacker22:35
*** yifei has quit IRC22:39
*** sripriya has joined #tacker22:46
sripriyatrozet: right22:46
*** sripriya has quit IRC22:51
*** gongysh has quit IRC23:08
*** sripriya has joined #tacker23:14
openstackgerritMerged openstack/python-tackerclient: Update reno for stable/newton  https://review.openstack.org/36496523:26
sridhar_ramsripriya: can you respin https://review.openstack.org/#/c/351431 ?23:35
sripriyasridhar_ram: sure, will do it right away23:41
sridhar_ramsripriya: thanks23:43
openstackgerritSripriya Seetharam proposed openstack/tacker: Better handle vim domain exception  https://review.openstack.org/35143123:58

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