| *** lhcheng has quit IRC | 00:03 | |
| manikanta_ | sridhar_ram_, Hi, Thanks for answering my query. So the existing CLI command to create VNFD should remain the way it is right ? | 00:05 |
|---|---|---|
| sridhar_ram_ | manikanta_: yes, not worth rewording them... | 00:07 |
| manikanta_ | sridhar_ram_: Ok | 00:08 |
| manikanta_ | sridhar_ram_, sripriya : Please review the patchset https://review.openstack.org/#/c/295207/ | 00:09 |
| sripriya | manikanta_: just responed to your comment, thanks. | 00:17 |
| *** Qiming has quit IRC | 00:24 | |
| *** arturt_ has quit IRC | 00:32 | |
| *** arturt_ has joined #tacker | 00:35 | |
| *** kkobayashi has quit IRC | 00:36 | |
| *** arturt_ has quit IRC | 00:39 | |
| *** arturt_ has joined #tacker | 00:43 | |
| *** arturt_ has quit IRC | 00:43 | |
| *** arturt_ has joined #tacker | 00:54 | |
| *** arturt_ has quit IRC | 00:55 | |
| *** arturt_ has joined #tacker | 00:57 | |
| openstackgerrit | Manikantha Srinivas Tadi proposed openstack/tacker-horizon: Display VNF instance details in Tacker Horizon. https://review.openstack.org/295207 | 01:04 |
| *** amotoki has quit IRC | 01:08 | |
| *** kkobayashi has joined #tacker | 01:25 | |
| openstackgerrit | Hideki Saito proposed openstack/python-tackerclient: Fix incompatible code with python3 for tox pep8 test https://review.openstack.org/319215 | 01:25 |
| *** Qiming has joined #tacker | 01:26 | |
| *** amotoki has joined #tacker | 01:48 | |
| *** amotoki has quit IRC | 01:56 | |
| *** kkobayashi has quit IRC | 01:58 | |
| *** arturt_ has quit IRC | 01:59 | |
| *** amotoki has joined #tacker | 01:59 | |
| manikanta_ | sridhar_ram_, sripriya : The tosca templates under tacker/samples/tosca-templates/vnfd are generic now, or used only specific to devstack ? | 02:00 |
| *** arturt_ has joined #tacker | 02:08 | |
| *** amotoki has quit IRC | 02:09 | |
| *** arturt_ has quit IRC | 02:10 | |
| *** kkobayashi has joined #tacker | 02:11 | |
| *** amotoki has joined #tacker | 02:18 | |
| sridhar_ram_ | manikanta_: they do use network names created by Tacker devstack scripts. However they all shd work for generic use as long as correct network names, image or flavor ids are passed | 02:32 |
| manikanta_ | manikanta_, I find some of them are not using Tacker devstack scripts for example, net_mgmt, Hence i got this doubt | 02:38 |
| manikanta_ | i mean network names created by tacker devstack script | 02:39 |
| *** vishwanathj has joined #tacker | 02:52 | |
| *** manikanta_ has quit IRC | 02:52 | |
| *** manikanta_ has joined #tacker | 02:56 | |
| *** manikanta_ has quit IRC | 02:57 | |
| *** manikanta_tadi has quit IRC | 02:57 | |
| *** arturt_ has joined #tacker | 02:58 | |
| *** vishwanathj has quit IRC | 02:58 | |
| *** manikanta_tadi has joined #tacker | 03:03 | |
| *** manikanta_tadi has quit IRC | 03:03 | |
| *** lhcheng has joined #tacker | 03:27 | |
| *** KanagarajM has joined #tacker | 03:33 | |
| sripriya | lhcheng: ping | 03:36 |
| *** sripriya_ has joined #tacker | 03:42 | |
| *** sripriya has quit IRC | 03:46 | |
| *** arturt_ has quit IRC | 03:50 | |
| *** vishnoianil has quit IRC | 03:50 | |
| lhcheng | hey sripriya_ | 03:54 |
| sripriya_ | lhcheng: had a question regarding https://review.openstack.org/#/c/295207/15/tacker_horizon/openstack_dashboard/dashboards/nfv/vnfmanager/templates/vnfmanager/vdu_details.html@22 | 03:55 |
| sripriya_ | lhcheng: how does that work? based on dictionary keys? | 03:55 |
| sripriya_ | lhcheng: i'm confused with actualy vnf dictionary parent and the dictionary keys here | 03:56 |
| lhcheng | that code refers to this: https://review.openstack.org/#/c/295207/15/tacker_horizon/openstack_dashboard/dashboards/nfv/vnfmanager/views.py@98 | 03:59 |
| lhcheng | but if mgmt_url is None, mgmt_url.items won't work | 03:59 |
| lhcheng | having vnf["vnf"] seems redundant | 04:00 |
| lhcheng | in the html template code, it is accessed by vnf.vnf.mgmt_url | 04:00 |
| sripriya_ | lhcheng: thanks, but why vnf.vnf --> does it mean vnf variable name and then the actual vnf key? | 04:01 |
| *** kkobayashi has quit IRC | 04:01 | |
| *** sripriya__ has joined #tacker | 04:04 | |
| lhcheng | yes, it is the name of the variable in the context | 04:06 |
| lhcheng | coming from here: https://review.openstack.org/#/c/295207/15/tacker_horizon/openstack_dashboard/dashboards/nfv/vnfmanager/tabs.py@84 | 04:06 |
| *** sripriya_ has quit IRC | 04:07 | |
| lhcheng | that's refer to the vnf object, and the vnf object has a dict with "vnf" key in it | 04:07 |
| sripriya__ | lhcheng: you mean L87? | 04:07 |
| lhcheng | https://review.openstack.org/#/c/295207/15/tacker_horizon/openstack_dashboard/dashboards/nfv/vnfmanager/views.py@98 | 04:07 |
| lhcheng | sripriya__: yes, supposed to be L87 | 04:08 |
| sripriya__ | lhcheng: so it is something like {'vnf':{'vnf': {'mgmt_url': {<vdu, url>, <vdu, url>}}}} | 04:09 |
| lhcheng | {'vnf':{'vnf': {'mgmt_url': <json object>}}} | 04:11 |
| lhcheng | due to the call of json.loads | 04:11 |
| sripriya__ | lhcheng: thats right | 04:12 |
| sripriya__ | lhcheng: to avoid this , we could just do return self.tab_group.kwargs['vnf']} in L87 | 04:13 |
| *** kkobayashi has joined #tacker | 04:13 | |
| sripriya__ | lhcheng: and i assume it is the variable reference here and not the actul 'vnf' key in the variable | 04:13 |
| sripriya__ | kwargs['vnf'] | 04:14 |
| lhcheng | it should be https://review.openstack.org/#/c/295207/15/tacker_horizon/openstack_dashboard/dashboards/nfv/vnfmanager/views.py@98 that needs to be updated | 04:14 |
| lhcheng | no need for additional ["vnf"] | 04:14 |
| sripriya__ | lhcheng: that is the response received from the server | 04:15 |
| sripriya__ | lhcheng: somehting like {'vnf': {k1,, v1, k2, v2}} | 04:16 |
| lhcheng | I mean when making the assignment | 04:16 |
| *** dkushwaha_ has quit IRC | 04:16 | |
| sripriya__ | lhcheng: he is updating the already existing assignment | 04:16 |
| lhcheng | why does the tackerclient return a json response? | 04:16 |
| lhcheng | it should be returning a resource object at that point. | 04:17 |
| sripriya__ | the mgmt_url is a string on the server api | 04:17 |
| sripriya__ | so before sending the response the dictionary is converted to json object and sent | 04:17 |
| sripriya__ | and he decodes it from the response received | 04:18 |
| lhcheng | it is probably better to assign it to another attribute rather than overriding | 04:19 |
| lhcheng | this way, you still have access to the original value | 04:19 |
| sripriya__ | lhcheng: i agree, but again it is still part of 'vnf' key inside the vnf object | 04:21 |
| sripriya__ | like vnf['vnf']['mgmt_url_dict'] = <decoded value> | 04:22 |
| sripriya__ | lhcheng: ^^ | 04:32 |
| *** arturt_ has joined #tacker | 04:32 | |
| *** dkushwaha_ has joined #tacker | 04:33 | |
| KanagarajM | sripriya__, hello | 04:40 |
| sripriya__ | KanagarajM: hi | 04:40 |
| KanagarajM | sripriya__, for the db schema improvements, i was thinking to start with https://blueprints.launchpad.net/tacker/+spec/db-records-audit-support | 04:41 |
| KanagarajM | and like to get your view point on it | 04:41 |
| lhcheng | sripriya__: yeah, might more cleaner to put it into separate key | 04:41 |
| sripriya__ | KanagarajM: vishwanathj is handling this as part of audit trail spec which he will posting this week AFAIK | 04:42 |
| sripriya__ | KanagarajM: similar to how heat is doing with an 'event's table | 04:43 |
| KanagarajM | sripriya__, ok. | 04:44 |
| sripriya__ | KanagarajM: i actually have a question for you regarding db schema | 04:44 |
| KanagarajM | sripriya__, what is that? | 04:45 |
| sripriya__ | KanagarajM: do you know if is possible to handle unique key constraints for columnn in exisiting db | 04:45 |
| sripriya__ | KanagarajM: suppose i start introducing uniqueness for a certain column in my db table, | 04:46 |
| KanagarajM | you mean, how to set the unique key constraint to the existing column, which has already having data in it | 04:46 |
| sripriya__ | KanagarajM: yes! | 04:46 |
| sripriya__ | KanagarajM: it will throw Integrity Error for current data | 04:46 |
| KanagarajM | sripriya__, the moment you introduce the constraint, db will thru error | 04:47 |
| KanagarajM | yes | 04:47 |
| sripriya__ | KanagarajM: is there a way we can handle such error in sql scripts | 04:47 |
| KanagarajM | so as part of migration, first you have to migrate them to meet the constraint | 04:47 |
| sripriya__ | KanagarajM: you mean delete the duplicate entries in current data in db | 04:48 |
| sripriya__ | KanagarajM: and then run the migration script | 04:48 |
| sripriya__ | ? | 04:48 |
| KanagarajM | sripriya__, which colum you are trying | 04:48 |
| sripriya__ | this is for the name column for all resources | 04:49 |
| sripriya__ | KanagarajM: ^ | 04:49 |
| KanagarajM | sripriya__, which table? | 04:49 |
| KanagarajM | sripriya__, devices ? | 04:49 |
| sripriya__ | KanagarajM: we plan to introduce uniqueness for name column in vnf, vnfd and vim tables | 04:49 |
| sripriya__ | sorry i mean devices and other tables | 04:49 |
| *** lhcheng_ has joined #tacker | 04:50 | |
| KanagarajM | sripriya__, ok, the problem is, the names are visible to user, so the moment , we introduce the fixing to make name as unique, it will shown up to the user | 04:50 |
| sripriya__ | KanagarajM: yes it has an user impact and that is fine | 04:51 |
| KanagarajM | so, we need to document it in the release notes, and as part of the migration, bring up some logic to make the existing names are unique. | 04:52 |
| *** lhcheng has quit IRC | 04:52 | |
| sripriya__ | KanagarajM: yes we need to note this, and yup, we need to handle this in our scripts | 04:52 |
| KanagarajM | sripriya__, and if user wants to change to diff name then you could given an update request vis api | 04:53 |
| sripriya__ | KanagarajM: does heat or in general openstack projects have dealt such a requirement? | 04:53 |
| *** dkushwaha_ has quit IRC | 04:54 | |
| KanagarajM | sripriya__, you could do this as part of db migration scripts (alembic): 1. make sure all the exsiting names are unique, by using some logic, 2. introduce the unique constraint | 04:54 |
| KanagarajM | sripriya__, in heat, I don't remember such a change happened. | 04:55 |
| sripriya__ | KanagarajM: regarding 1. yes that is what i'm thinking, modify existing data to make them unique | 04:56 |
| sripriya__ | KanagarajM: ok | 04:57 |
| KanagarajM | sripriya__, ok. sounds good ! | 04:57 |
| *** arturt_ has quit IRC | 05:11 | |
| *** kkobayashi has quit IRC | 05:15 | |
| *** arturt_ has joined #tacker | 05:18 | |
| *** sripriya__ has quit IRC | 05:18 | |
| *** Ravikiran_K has joined #tacker | 05:21 | |
| *** vishnoianil has joined #tacker | 05:22 | |
| *** arturt_ has quit IRC | 05:31 | |
| *** arturt_ has joined #tacker | 05:31 | |
| *** arturt_ has quit IRC | 05:34 | |
| *** manikanta_tadi has joined #tacker | 05:56 | |
| *** lhcheng has joined #tacker | 06:06 | |
| *** lhcheng_ has quit IRC | 06:09 | |
| *** kkobayashi has joined #tacker | 06:12 | |
| *** arturt_ has joined #tacker | 06:35 | |
| *** arturt_ has quit IRC | 06:42 | |
| *** Ravikiran_K has quit IRC | 07:08 | |
| *** zeih has joined #tacker | 07:23 | |
| *** arturt_ has joined #tacker | 07:38 | |
| *** arturt_ has quit IRC | 07:43 | |
| *** lhcheng has quit IRC | 07:48 | |
| *** kkobayashi has quit IRC | 08:08 | |
| *** dmk0202 has joined #tacker | 08:28 | |
| *** arturt_ has joined #tacker | 08:39 | |
| *** arturt_ has quit IRC | 08:44 | |
| *** zeih has quit IRC | 08:47 | |
| *** zeih has joined #tacker | 08:50 | |
| *** mbound has joined #tacker | 08:55 | |
| *** manikanta_tadi has quit IRC | 08:57 | |
| *** amotoki has quit IRC | 09:00 | |
| *** manikanta_tadi has joined #tacker | 09:09 | |
| *** tbh has joined #tacker | 09:12 | |
| *** zeih_ has joined #tacker | 09:22 | |
| *** zeih has quit IRC | 09:22 | |
| *** arturt_ has joined #tacker | 09:40 | |
| *** manikanta_tadi has quit IRC | 09:44 | |
| *** arturt_ has quit IRC | 09:45 | |
| *** amotoki has joined #tacker | 09:47 | |
| *** zeih_ has quit IRC | 09:55 | |
| *** zeih has joined #tacker | 09:58 | |
| *** tbh has quit IRC | 10:16 | |
| *** zeih has quit IRC | 10:17 | |
| *** zeih has joined #tacker | 10:23 | |
| *** zeih has quit IRC | 10:28 | |
| *** Qiming has quit IRC | 10:30 | |
| *** fxpester has quit IRC | 10:35 | |
| *** arturt_ has joined #tacker | 10:41 | |
| *** arturt_ has quit IRC | 10:45 | |
| *** zeih has joined #tacker | 10:58 | |
| *** fxpester has joined #tacker | 10:58 | |
| *** manikanta_tadi has joined #tacker | 11:00 | |
| *** amotoki has quit IRC | 11:17 | |
| *** openstackgerrit has quit IRC | 11:18 | |
| *** zeih has quit IRC | 11:18 | |
| *** openstackgerrit has joined #tacker | 11:19 | |
| *** Qiming has joined #tacker | 11:21 | |
| *** amotoki has joined #tacker | 11:34 | |
| *** arturt_ has joined #tacker | 11:41 | |
| *** arturt_ has quit IRC | 11:46 | |
| *** bobh has joined #tacker | 11:46 | |
| *** amotoki has quit IRC | 11:54 | |
| *** zeih has joined #tacker | 12:04 | |
| *** bobh has quit IRC | 12:19 | |
| *** tbh has joined #tacker | 12:25 | |
| *** zeih has quit IRC | 12:30 | |
| *** tbh_ has joined #tacker | 12:31 | |
| *** tbh has quit IRC | 12:33 | |
| *** arturt_ has joined #tacker | 12:42 | |
| *** arturt_ has quit IRC | 12:47 | |
| *** manikanta_tadi has quit IRC | 12:59 | |
| *** zeih has joined #tacker | 13:11 | |
| *** tbh_ has quit IRC | 13:26 | |
| *** tbh_ has joined #tacker | 13:27 | |
| *** tbh_ has quit IRC | 13:29 | |
| *** KanagarajM has quit IRC | 13:30 | |
| *** tbh_ has joined #tacker | 13:32 | |
| *** tbh_ has quit IRC | 13:34 | |
| *** tbh_ has joined #tacker | 13:36 | |
| *** arturt_ has joined #tacker | 13:43 | |
| *** arturt_ has quit IRC | 13:48 | |
| *** tbh_ has quit IRC | 13:55 | |
| *** zeih has quit IRC | 14:09 | |
| *** zeih_ has joined #tacker | 14:09 | |
| openstackgerrit | Trevor McCasland proposed openstack/python-tackerclient: mox to mock refactor https://review.openstack.org/313165 | 14:09 |
| *** twm2016 has joined #tacker | 14:22 | |
| *** mbuil has joined #tacker | 14:26 | |
| mbuil | Hi guys, I am working in OPNFV trying to create a test case for Tacker + SFC. Does anybody know if it is possible to add a parameter in the vnfd so that the VNF gets a floating IP too? | 14:28 |
| trozet | sridhar_ram_:^ | 14:28 |
| *** KanagarajM has joined #tacker | 14:35 | |
| *** arturt_ has joined #tacker | 14:44 | |
| sridhar_ram_ | mbuil: this is a reasonable ask, need a minor enhancement to bring this in. It along the same lines as adding VNFD / VDU parameter for secgroup and key_name. | 14:47 |
| sridhar_ram_ | mbuil: so, not supported today but can be added with a small effort. | 14:48 |
| *** arturt_ has quit IRC | 14:49 | |
| *** zeih has joined #tacker | 14:50 | |
| *** zeih_ has quit IRC | 14:51 | |
| *** mbuil1 has joined #tacker | 14:55 | |
| *** mbuil has quit IRC | 14:57 | |
| *** zeih has quit IRC | 14:59 | |
| *** amotoki has joined #tacker | 15:03 | |
| *** Qiming has quit IRC | 15:09 | |
| mbuil1 | ok, thanks | 15:17 |
| *** amotoki_ has joined #tacker | 15:21 | |
| *** arturt_ has joined #tacker | 15:22 | |
| *** amotoki has quit IRC | 15:24 | |
| *** arturt_ has quit IRC | 15:25 | |
| *** amotoki_ has quit IRC | 15:34 | |
| *** dmk0202 has quit IRC | 15:49 | |
| *** manikanta_tadi has joined #tacker | 15:52 | |
| *** sridhar_ram has joined #tacker | 15:53 | |
| *** sridhar_ram has left #tacker | 15:54 | |
| *** KanagarajM has quit IRC | 15:57 | |
| *** tbh has joined #tacker | 16:15 | |
| *** tbh has quit IRC | 16:17 | |
| *** tbh has joined #tacker | 16:17 | |
| *** mbound has quit IRC | 16:18 | |
| *** lhcheng has joined #tacker | 16:19 | |
| *** arturt_ has joined #tacker | 16:26 | |
| *** arturt_ has quit IRC | 16:31 | |
| *** tbh has quit IRC | 16:32 | |
| *** mbuil1 has left #tacker | 16:46 | |
| *** sripad has joined #tacker | 16:46 | |
| *** sripad has quit IRC | 16:49 | |
| *** santoshk has joined #tacker | 16:54 | |
| *** tbh has joined #tacker | 17:00 | |
| *** manikanta_tadi2 has joined #tacker | 17:02 | |
| *** manikanta_tadi2 has quit IRC | 17:03 | |
| *** sripriya has joined #tacker | 17:11 | |
| *** santoshk has quit IRC | 17:13 | |
| *** arturt_ has joined #tacker | 17:27 | |
| *** manikanta_tadi has quit IRC | 17:32 | |
| *** arturt_ has quit IRC | 17:32 | |
| trozet | sridhar_ram_: ping? | 17:48 |
| sridhar_ram_ | trozet: pong | 17:48 |
| trozet | sridhar_ram_: an example: in the tosca parser its called "constituent_vnfs", but in the spec its just "vnf:" | 17:48 |
| trozet | sridhar_ram_: connection_point is also not listed in the spec | 17:49 |
| * sridhar_ram_ is looking up | 17:49 | |
| trozet | dependent_virtual_link is "vl:" in the spec | 17:49 |
| sridhar_ram_ | trozet: http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/csd03/tosca-nfv-v1.0-csd03.html#_Toc447714727 | 17:51 |
| sridhar_ram_ | trozet: i do see "constituent_vnfs" in tosca.groups.nfv.VNFFG | 17:52 |
| sridhar_ram_ | trozet: sec 10.6.4 specifically | 17:52 |
| trozet | sridhar_ram_: I see what you ares saying, i waas looking at 11.2 | 17:52 |
| trozet | sridhar_ram_: it is contradictory... | 17:53 |
| sridhar_ram_ | trozet: argh.. the examples are messed up... | 17:53 |
| sridhar_ram_ | trozet: we are planning to fix them in CSD04 (next spec revision) | 17:53 |
| trozet | sridhar_ram_: ok so i should ignore the example, and follow whats listed as explicit properties | 17:54 |
| *** s3wong has joined #tacker | 17:54 | |
| sridhar_ram_ | trozet: yes, more important.. follow what is in tosca-parser right now.. so that you don't waste time | 17:54 |
| trozet | sridhar_ram_: OK so "connection_point", shouldnt that be "connection_points" | 17:54 |
| trozet | sridhar_ram_: ok | 17:54 |
| trozet | sridhar_ram_: will update | 17:54 |
| sridhar_ram_ | trozet: yes, stick with tosca-parser defs for now... | 17:55 |
| sridhar_ram_ | trozet: thanks | 17:55 |
| sridhar_ram_ | sripriya: s3wong bobh: i think vnffg spec has iterated enough (imo)... please land your aye / nah votes | 17:56 |
| s3wong | sridhar_ram_, trozet: yeah, sorry about that, I haven't looked at the latest one yet | 17:57 |
| trozet | ill push another revision soon | 17:57 |
| *** santoshk has joined #tacker | 17:58 | |
| s3wong | trozet: prolific!!! | 18:00 |
| *** twm2016 has quit IRC | 18:00 | |
| *** bharatht_ has joined #tacker | 18:01 | |
| *** tbh has quit IRC | 18:05 | |
| *** bharatht_ has quit IRC | 18:05 | |
| sripriya | sridhar_ram: overall the spec looked fine for me, I will wait for trozet's new patch to leave my +1 | 18:12 |
| trozet | thanks sripriya | 18:13 |
| sripriya | trozet: thank you trozet, you did a great job on the spec. appreciate your patience. | 18:14 |
| *** vishwanathj has joined #tacker | 18:19 | |
| trozet | :) | 18:23 |
| *** vishnoianil has quit IRC | 18:23 | |
| *** tbh has joined #tacker | 18:27 | |
| *** arturt_ has joined #tacker | 18:28 | |
| *** twm2016 has joined #tacker | 18:29 | |
| *** arturt_ has quit IRC | 18:33 | |
| trozet | sridhar_ram_: how come in the VNFD samples in the repo, there is no usage of tosca.nodes.nfv.VNF ? | 18:35 |
| trozet | sripriya:^ | 18:38 |
| trozet | Seems like there should be another block of yaml "node_types" in the VNFD that describes the VNF itself outside of hte "topology_template" | 18:38 |
| sridhar_ram_ | trozet: it is implicit for VNFD.. NSD will have node of type of "tosca.nodes.nfv.VNF" | 18:41 |
| trozet | sridhar_ram_: ok thats what I assumed | 18:41 |
| trozet | sridhar_ram_: but for defining a VNF as NSH aware, i would think the appropriate place to do that would be in tosca.nodes.nfv.VNF | 18:42 |
| trozet | sridhar_ram_: are we able to specify it in the VNFD today? | 18:43 |
| sridhar_ram_ | trozet: hmm.. i'm thinking about a Multi-VDU VNF ...where it is would be more appropriate to mark specific VDUs to be nsh aware | 18:43 |
| trozet | sridhar_ram_: is it more appropriate to mark per VDU? I'm not sure it seems like a VNF level attribute, since the port that is exposed as the VNF external port will have to be NSH capable | 18:44 |
| sridhar_ram_ | trozet: help me here, is NSH awareness a property of a NIC or the whole VNF? | 18:46 |
| trozet | sridhar_ram_: i think it is a property of the VNF itself. It's networking stack has to be able to process NSH headers and know how to interpret them | 18:47 |
| trozet | sridhar_ram_: the NIC just needs to be able to accept encapsulation that carries the NSH | 18:47 |
| trozet | sridhar_ram_: outside of NSH, wouldn't there be cases where a user wants to define properties of the VNF itself, and not per VDU? | 18:50 |
| * sridhar_ram_ wanders back after getting interrupted ... | 18:59 | |
| sridhar_ram_ | trozet: yes, within tosca-nfv group we discussed about introducing an "envelope node" within VNFD that desc the VNF itself | 19:02 |
| sridhar_ram_ | trozet: i'm open to having this part enhanced if needed | 19:02 |
| trozet | sridhar_ram_: so today if I added valid tosca parser VNF type: https://github.com/openstack/tosca-parser/blob/master/toscaparser/extensions/nfv/TOSCA_nfv_definition_1_0.yaml#L26 | 19:04 |
| trozet | sridhar_ram_: into my VNFD...would tacker accept it, but ignore it? Or would it blow up? | 19:04 |
| sridhar_ram_ | AFAIK.. it should accept | 19:05 |
| trozet | sridhar_ram_: ok then thats fine. I'm going to list NSH as a VNF property then | 19:07 |
| sridhar_ram_ | trozet: sounds good | 19:07 |
| trozet | thanks | 19:07 |
| *** vishnoianil has joined #tacker | 19:12 | |
| trozet | sridhar_ram_, sripriya: is this a bug? https://github.com/openstack/tosca-parser/blob/master/toscaparser/extensions/nfv/TOSCA_nfv_definition_1_0.yaml#L239 | 19:21 |
| *** tbh has quit IRC | 19:21 | |
| trozet | sridhar_ram_: targets shouldn't be under properties | 19:21 |
| sridhar_ram_ | trozet: yes.. again, looks like they picked up from the "bad" example in the spec | 19:29 |
| *** arturt_ has joined #tacker | 19:30 | |
| trozet | sridhar_ram_: ok i checked out the tosca-parser code and attempting to fix it | 19:30 |
| sridhar_ram_ | trozet: however, you would be better of sticking with this "bug" for now, until it gets fixed in the tosca-parser | 19:30 |
| sridhar_ram_ | trozet: sure.. that would work as well ! | 19:30 |
| trozet | sridhar_ram_: bobh is familiar with that code, incase I have questions... is there anyone else? | 19:31 |
| sridhar_ram_ | tbh also participates... | 19:31 |
| sridhar_ram_ | trozet: ptl Sahdev (spzala) is super supportive of tacker's needs .. | 19:31 |
| trozet | sridhar_ram_: thanks | 19:32 |
| *** tbh has joined #tacker | 19:33 | |
| *** arturt_ has quit IRC | 19:36 | |
| openstackgerrit | Sridhar Ramaswamy proposed openstack/tacker: Add support to display error_reason for the VNF https://review.openstack.org/255463 | 19:38 |
| *** tbh has quit IRC | 20:01 | |
| trozet | sridhar_ram_: I fixed it, but now im finding more of TOSCA conflicts with itself.. | 20:11 |
| trozet | sridhar_ram_: how do the TOSCA doc revisions go csd<num> where later num is later revision? | 20:11 |
| trozet | I also see csprd02 | 20:12 |
| trozet | http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/ | 20:12 |
| *** s3wong has quit IRC | 20:21 | |
| *** s3wong has joined #tacker | 20:21 | |
| *** arturt_ has joined #tacker | 20:32 | |
| *** arturt_ has quit IRC | 20:38 | |
| trozet | sridhar_ram_: ping? | 20:49 |
| openstackgerrit | Tim Rozet proposed openstack/tacker-specs: Adds Tacker VNFFG/SFC spec https://review.openstack.org/292196 | 20:55 |
| *** twm2016 has quit IRC | 21:08 | |
| sridhar_ram_ | trozet: i'm back.. yes, later num is the newer version | 21:29 |
| trozet | sridhar_ram_: there is a conflict in the spec | 21:29 |
| sridhar_ram_ | current latest is csd03 .. http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/ | 21:29 |
| trozet | sridhar_ram_: http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/TOSCA-Simple-Profile-YAML-v1.0.html | 21:29 |
| openstackgerrit | Merged openstack/tacker: Updates method details in monitor-driver guide https://review.openstack.org/314526 | 21:30 |
| sridhar_ram_ | trozet: oh, the major version is still v1.0 within that there are newer updates.. csd01, csd02, csd-3 | 21:30 |
| sridhar_ram_ | trozet: *csd03 | 21:30 |
| trozet | sridhar_ram_: one sec i need to clear this up | 21:31 |
| sridhar_ram_ | trozet: sure | 21:31 |
| trozet | sridhar_ram_: http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csd05/TOSCA-Simple-Profile-YAML-v1.0-csd05.html | 21:31 |
| trozet | sridhar_ram_: 3.6.10 | 21:31 |
| trozet | sridhar_ram_: they switch targets to "members" | 21:32 |
| sridhar_ram_ | trozet: that is not the NFV profile... | 21:32 |
| trozet | sridhar_ram_: that is the groups | 21:32 |
| trozet | sridhar_ram_: that VNFFG derives from | 21:32 |
| sridhar_ram_ | trozet: ah, sure... | 21:33 |
| trozet | sridhar_ram_: but in the notes Section 3.7.5: Group def.: Changed ‘members’ to ‘targets’ as agreed by work group. | 21:33 |
| trozet | sridhar_ram_: that statement is crossed out | 21:33 |
| trozet | sridhar_ram_: but then in the NFV spec, it shows it as "targets" | 21:33 |
| *** arturt_ has joined #tacker | 21:33 | |
| trozet | im really confused as to what hte correct way is... | 21:33 |
| trozet | or the intention | 21:33 |
| * sridhar_ram_ is looking up groups in simple yaml doc | 21:33 | |
| *** arturt_ has quit IRC | 21:37 | |
| trozet | sridhar_ram_: search 3.7.5 | 21:37 |
| sridhar_ram_ | trozet: members seems the correct usage... | 21:41 |
| sridhar_ram_ | trozet: there is some confusion between groups and policy definitions ... the later uses "targets" and the former used "members" | 21:42 |
| trozet | sridhar_ram_: yep i noticed that | 21:42 |
| sridhar_ram_ | trozet: do u've the notes so far for the fixes required / errors noticed in the tosca-nfv spec ? | 21:44 |
| trozet | sridhar_ram_: well i came up with a patch that fixed everything | 21:44 |
| trozet | sridhar_ram_: but it used "targets" instead of "members" | 21:45 |
| trozet | sridhar_ram_: if hte intention is to use "members" then I know what to change in tosca-parser | 21:45 |
| sridhar_ram_ | trozet: okay.. and "members" shouldn't be under properties but stand alongside it, correct ? | 21:45 |
| trozet | sridhar_ram_: it shouldn't even be in the NFV spec, because its defined as an attribute of groups itself | 21:46 |
| sridhar_ram_ | trozet: .. but the VNFFG properties listed (like constituent_vnfs) still need to go into NFV spec... | 21:48 |
| trozet | sridhar_ram_: yeah added those | 21:48 |
| *** lhcheng has quit IRC | 21:59 | |
| sridhar_ram_ | trozet: i just put together this etherpad for the running issues .. https://etherpad.openstack.org/p/tacker-tosca-issues-backlog | 22:03 |
| sridhar_ram_ | trozet: can u please glance thru' ? This will help for me to push these fixes in the spec... | 22:03 |
| *** dkushwaha has quit IRC | 22:20 | |
| *** uck has joined #tacker | 22:23 | |
| *** arturt_ has joined #tacker | 22:25 | |
| uck | Folks, I was attempting to translate a tosca file with tosca.nodes.nfv.VNF objects. heat-translator version 0.5.0 give a key error. It runs fine with tosca.nodes.nfv.VDU types. I was checking the sample Tosca files in Tacker and it looks all use tosca.nodes.nfv.VDU. Does tacker consume any Tosca file with tosca.nodes.nfv.VNF type? | 22:34 |
| *** ksantoshk has joined #tacker | 22:35 | |
| *** sripriya_ has joined #tacker | 22:35 | |
| *** sridhar_ram1 has joined #tacker | 22:35 | |
| *** santoshk has quit IRC | 22:38 | |
| *** sripriya has quit IRC | 22:38 | |
| *** sridhar_ram1 has quit IRC | 22:48 | |
| *** lhcheng has joined #tacker | 22:50 | |
| *** arturt_ has quit IRC | 22:51 | |
| *** arturt_ has joined #tacker | 22:55 | |
| *** arturt_ has quit IRC | 22:57 | |
| sridhar_ram_ | uck: the plan to make use of tosca.nodes.nfv.VNF type when we introduce NSD support ... | 23:03 |
| sridhar_ram_ | uck: do you've a sample template yaml file that errors out ? what specific error are you getting ? | 23:04 |
| uck | I used a sample VNF file from tosca-parser which I also use for Domino feature testing. It defines dummy VNFs with vendor ID, description, etc. | 23:05 |
| uck | https://github.com/openstack/tosca-parser/blob/master/toscaparser/extensions/nfv/tests/data/tosca_helloworld_nfv.yaml | 23:08 |
| uck | it gives a key error, i.e., tosca.nodes.nfv.VNF is not accepted as a valid key. | 23:08 |
| uck | File "/Users/kozat/tosca/heat-translator/translator/hot/translate_node_templates.py", line 174, in _translate_nodetemplates | 23:13 |
| uck | hot_node = TOSCA_TO_HOT_TYPE[base_type.type](node) | 23:13 |
| uck | KeyError: 'tosca.nodes.nfv.VNF' | 23:13 |
| *** vishwana_ has joined #tacker | 23:21 | |
| *** sripriya has joined #tacker | 23:21 | |
| *** santoshk has joined #tacker | 23:21 | |
| *** ksantoshk has quit IRC | 23:23 | |
| *** vishwanathj has quit IRC | 23:23 | |
| *** sripriya_ has quit IRC | 23:24 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!