Monday, 2016-08-22

« Sunday, 2016-08-21 Index Tuesday, 2016-08-23 »
*** bobh has joined #tacker00:16
*** bobh has quit IRC00:22
*** prashantD_ has joined #tacker01:05
*** bobh has joined #tacker01:18
*** bobh has quit IRC01:23
*** trozet has joined #tacker02:03
*** bobh has joined #tacker02:19
*** yifei has quit IRC02:19
*** yifei1 has joined #tacker02:19
*** yifei1 is now known as yifei02:21
*** bobh has quit IRC02:24
*** trozet has quit IRC02:31
*** bobh has joined #tacker02:31
*** bobh has quit IRC03:22
*** bobh has joined #tacker03:26
*** vishwanathj has joined #tacker03:28
*** diga has joined #tacker03:44
*** bobh has quit IRC04:04
*** vishwanathj has quit IRC04:11
*** janki has joined #tacker04:20
*** prashantD_ has quit IRC04:35
*** amotoki has joined #tacker05:11
*** links has joined #tacker05:38
*** links has quit IRC05:38
*** diga has quit IRC05:44
*** Murali has quit IRC05:53
*** saju_m has joined #tacker06:09
*** yifei has quit IRC06:46
*** yifei1 has joined #tacker06:46
*** yifei1 is now known as yifei06:48
*** yifei has quit IRC06:52
openstackgerritMerged openstack/tacker: Enables soft deletion for VIM, VNFD and VNF  https://review.openstack.org/32571807:01
openstackgerritMerged openstack/tacker: Adds common services plugin for audit support  https://review.openstack.org/32610207:19
openstackgerritMerged openstack/tacker: Logs events for VIM, VNFD and VNF operations  https://review.openstack.org/34915307:28
*** yifei has joined #tacker07:31
*** KanagarajM has joined #tacker09:55
*** KanagarajM has quit IRC10:08
*** tbh has joined #tacker10:22
*** bharatht_ has joined #tacker10:22
*** tbh has quit IRC10:22
*** bharatht_ is now known as tbh10:22
*** janki has quit IRC10:30
*** janki has joined #tacker10:31
*** prashantD_ has joined #tacker10:31
*** prashantD_ has quit IRC10:36
*** openstackgerrit has quit IRC11:03
*** openstackgerrit has joined #tacker11:04
*** amotoki has quit IRC11:15
*** amotoki has joined #tacker11:15
*** afranc has quit IRC11:17
*** afranc has joined #tacker11:18
*** tbh has quit IRC11:21
*** openstackstatus has quit IRC11:36
*** openstackstatus has joined #tacker11:39
*** ChanServ sets mode: +v openstackstatus11:39
*** saju_m has quit IRC11:51
*** neel has joined #tacker11:59
*** saju_m has joined #tacker12:03
*** neel has quit IRC12:05
*** haiwei has quit IRC12:08
*** bobh has joined #tacker12:37
*** uck has joined #tacker12:53
*** DaveJ__ has joined #tacker12:56
*** bobh has quit IRC12:57
*** mike_m has joined #tacker13:06
*** mike_m has quit IRC13:08
*** mike_m has joined #tacker13:09
*** trozet has joined #tacker13:21
*** tbh has joined #tacker13:23
*** bharatht_ has joined #tacker13:23
*** bharatht_ has quit IRC13:26
*** bobh has joined #tacker13:30
*** bobh has quit IRC13:35
*** bobh has joined #tacker13:41
*** KanagarajM has joined #tacker13:41
*** vishwanathj has joined #tacker13:44
jankisridhar_ram, ping13:46
*** diga has joined #tacker14:01
*** KanagarajM has quit IRC14:03
*** uck has quit IRC14:28
openstackgerritvishwanath jayaraman proposed openstack/tacker: Adds functional tests for common services plugin  https://review.openstack.org/35867814:36
*** tbh has quit IRC14:40
*** vishwanathj has quit IRC14:53
*** vishwanathj has joined #tacker14:53
*** janki has quit IRC15:12
*** uck has joined #tacker15:17
*** uck has quit IRC15:22
*** prashantD has joined #tacker15:44
*** uck has joined #tacker16:01
*** uck has quit IRC16:01
*** janki has joined #tacker16:09
jankisridhar_ram, ping16:09
*** DaveJ__ has quit IRC16:31
sridhar_ramjanki: pong16:34
jankisridhar_ram, for BP for creating VNF from template directly, should I send the template file as an "attribute" or a seaparate variable?16:36
jankicontent type would be json to be in line with this bug https://bugs.launchpad.net/tacker/+bug/159136116:36
openstackLaunchpad bug 1591361 in tacker "Fix data handling for vnfd, config and param yaml templates" [Medium,New] - Assigned to Janki Chhatbar (jankihchhatbar)16:36
sridhar_ramjanki: content type shd definitely be json. However i'd suggest some other meaningful name instead of sending this as "attribute"16:40
jankisridhar_ram, i am thinking of keeping it as "vnfd-file" or "vnfd-template"16:41
sridhar_ram"vnfd" is probably sufficient16:41
sridhar_ram... definitely not "-file"16:42
jankiWhat I initially meant was, shoud it be a part of "attributes" like https://github.com/openstack/python-tackerclient/blob/master/tackerclient/tacker/v1_0/vm/vnf.py#L10916:42
jankiwon't just "vnfd" be confusing.16:42
jankicurrently, there are vnfd-name and vnfd-id options. with this feature, there would be vnfd-name, vnfd-id and nfd-file/template16:43
jankisridhar_ram, ^^16:43
sridhar_ramjanki: then the next choice would be "vnfd-template"16:45
sridhar_ramjanki: .. which btw shd get precedence over vnfd-id/name if both are specified16:45
*** diga has quit IRC16:46
jankisridhar_ram, ok. will go with vnfd-template. would it be part of "attributes" like https://github.com/openstack/python-tackerclient/blob/master/tackerclient/tacker/v1_0/vm/vnf.py#L109 or a separate entity in API?16:46
jankisridhar_ram, precedence - noted16:46
sridhar_ramjanki: separate entity outside "attributes"16:47
jankisridhar_ram, ok. I noticed that this BP is targeted for Ocata right?16:48
sridhar_ramjanki: that's exactly what I was abt to talk to u16:48
sridhar_ramjanki: what is ur estimate to finish this?16:48
jankisridhar_ram, I can finish in 2 days max.16:49
sridhar_ramjanki: I'd love to have this in Newton but it has client changes16:49
jankiboth the client and server16:49
*** bobh has quit IRC16:49
jankisridhar_ram, we can have this in Newton and this bug https://bugs.launchpad.net/tacker/+bug/1591361 in Ocata16:49
openstackLaunchpad bug 1591361 in tacker "Fix data handling for vnfd, config and param yaml templates" [Medium,New] - Assigned to Janki Chhatbar (jankihchhatbar)16:49
sridhar_ramjanki: we are cutting close to the client release deadline (this Friday).16:50
sridhar_ramjanki: for server side, we have sometime..so if u can take care of the API parts in both the client and server we have a chance of making it in Newton16:51
jankisridhar_ram, Can work extra and finish it in by wednesday eod16:52
sridhar_ramjanki: cool, I'll put this in the agenda in tomorrow's mtg16:52
jankisridhar_ram, ok.16:52
jankiearlier mentioned bug too is assigned to me and is under Newton priority as per the etherpad. Could that be moved to Ocata?16:53
jankisridhar_ram, https://etherpad.openstack.org/p/tacker-newton-release-priority16:54
* sridhar_ram is checking16:54
sridhar_ramjanki: u mean support vnfd template using json ?16:55
jankisridhar_ram, yes. Not just vnfd template but param and config files too16:56
jankisridhar_ram, this bug - https://bugs.launchpad.net/tacker/+bug/159136116:57
openstackLaunchpad bug 1591361 in tacker "Fix data handling for vnfd, config and param yaml templates" [Medium,New] - Assigned to Janki Chhatbar (jankihchhatbar)16:57
sridhar_ramjanki: okay, we can punt that to ocata16:57
jankisridhar_ram, cool. thanks16:57
*** janki has quit IRC17:00
*** amotoki has quit IRC17:06
*** sripriya has joined #tacker17:10
*** uck has joined #tacker17:13
*** tbh has joined #tacker17:24
*** prashantD_ has joined #tacker17:34
*** prashantD has quit IRC17:38
*** bobh has joined #tacker17:50
*** prashantD has joined #tacker17:51
*** prashantD_ has quit IRC17:54
*** bobh has quit IRC17:54
trozetsridhar_ram, sripriya: ping?17:55
*** s3wong has joined #tacker17:58
*** bobh has joined #tacker17:58
sripriyatrozet: hello18:02
trozethi sripriya18:02
trozetsripriya: https://review.openstack.org/#/c/340838/22/tacker/vm/plugin.py18:03
trozetsripriya: the last comment I left there - Janki is saying thta the API expects a list?  Why is that? Something about specific to how it is included into the extension?18:04
sripriyatrozet: the url that gets invoked is an index call, i discussed this earlier in detail with janki18:05
sripriyatrozet: refert to my comment in https://review.openstack.org/#/c/340838/18/tacker/vm/plugin.py@63018:06
trozetsripriya: sure, but then it needs to be a real list, not a dictionary wrapped in a list...18:06
sripriyatrozet: we could have sent this as a dictionary to the api layer instead of list18:07
sripriyatrozet: but there are few assertions tha happen to the first element in the list https://github.com/openstack/tacker/blob/master/tacker/api/v1/base.py#L24918:07
trozetsripriya: why dont we just change it to be18:08
trozetsripriya: get_vnf_detail?18:08
trozetsripriya: wrapping it into a list doesn't make sense18:09
sripriyatrozet: the url wont invoke get on the detail18:09
sripriyatrozet: a show/get expects a resource id to the end in the url18:09
sripriyatrozet: only then will the plugin get_vnf_detail be invoked18:09
trozetsripriya: the resource is the vnf_id?18:10
sripriyatrozet: well in this case, it is expected to be the detail resource id18:11
sripriyatrozet: which again doesnt make sense18:11
trozetsripriya: lo.l18:11
trozetsripriya: cant we just change it to get get_vnf_detail, and the resource is vnf_id18:11
trozetsripriya: and returna  dict18:11
sripriyatrozet: you mean like /vnfs/<vnf_id>/details/<vnf_id>  ?18:12
trozetsripriya: hmm18:12
sripriyatrozet: :-)18:12
sripriyatrozet: these are some limitations we have in api layer18:13
trozetsripriya: so in the extension the 'details' section here https://review.openstack.org/#/c/340838/22/tacker/extensions/vnfm.py18:13
sripriyatrozet: the way the other projects do is to customize the index call from the wsgi layer and return whatever the resource wants to send18:13
trozetsripriya: provides that url extension of /vnf/<vnf_id>/details?18:13
sripriyatrozet: yes , a GET on /vnf/<vnf_id>/details18:14
trozetsripriya: ok.  Why not just move the details into the vnf itself18:14
trozetso /vnf/<vnf_id> returns the details included18:15
trozetand make it a dict18:15
sripriyatrozet: that was the earlier approach, but a regular VNF get response today has to make additional heat client calls everytime to fetch the redundant stack resource information18:16
trozetsripriya: I see18:16
sripriyatrozet: a GET on vnf can happen multiple times which has this additional info always invoked and sent18:17
sripriyatrozet: a GET workflow is expected to do a dump on resource , AFAIK18:17
trozetsripriya: ok I guess there is no way around this then18:17
trozetsripriya: so when I call the plugin method from VNFFG, I will just have to index into a list first18:18
sripriyatrozet: i burnt my head a lot on this and had to compromise with this “hack”, i understand this may not be the best way to to do this ‘details’ workflow18:18
trozetsripriya: sure, thanks for the explanation18:18
trozetsripriya: what about adding a get_vnf_detail18:19
sripriyatrozet: the way i assumed this to happen was to to pass extra parameter to the get/vnfs/<uuid> itself18:19
sripriyatrozet: with a verbose=true or whatever18:19
trozetsripriya: with /vnf/<vnf_id>/detail/CP11, for example?18:19
sripriyatrozet: that is doable18:20
trozetsripriya: that is what I want to do anyway in my code, because I already know the CP names18:20
sripriyatrozet: you want to a direct query on the resource id?18:20
sripriyatrozet: i see18:20
sripriyatrozet: but then you will have to do multiple GETS on cp resources of the same vnf right?18:21
trozetsripriya: yeah if they are in the same VNF18:21
trozetsripriya: I mean if it creates more patch iterations, then we can just leave it for later18:21
trozetsripriya: since time is of the essence, i can handle doing [0] :)18:22
sripriyatrozet: why do you need to index [0]?18:22
trozetsripriya: because the dictionary is returned back in a list18:22
trozetof one18:22
sripriyatrozet: can’t you expect it as a list?18:23
trozetsripriya: What do you mean?18:23
sripriyatrozet: do you consume the response as a list or a dict?18:24
trozetsripriya: well i need to fix it to pop the dict out of the list, because I expected it to be a dict:18:24
sripriyatrozet: i think it is better to do that instead of indexing [0]18:25
trozetsripriya: yeah18:26
sripriyatrozet: given the time constraints, let us plan to revisit this ‘details’  workflow in follow-ons18:27
trozetsripriya: makes sense18:27
trozetsripriya: do you mind reviewing https://review.openstack.org/#/c/347563/ ?18:28
sripriyatrozet: sure will do18:28
trozetsripriya: thanks!18:28
*** tbh has quit IRC18:52
*** uck has quit IRC19:09
*** mike_m has quit IRC19:49
*** uck has joined #tacker20:09
*** uck has quit IRC20:14
*** sripriya has quit IRC20:25
*** sripriya has joined #tacker20:30
*** bobh has quit IRC20:42
*** prashantD_ has joined #tacker21:03
*** prashantD has quit IRC21:07
*** uck has joined #tacker21:10
*** uck has quit IRC21:15
*** bobh has joined #tacker21:19
*** bobh has quit IRC22:04
*** prashantD__ has joined #tacker22:18
*** prashantD_ has quit IRC22:18
*** saju_m has quit IRC22:26
*** sripriya has quit IRC22:30
*** sripriya has joined #tacker22:37
sridhar_ramtrozet: sripriya: we need to wrap up vnf details patchset asap .. https://review.openstack.org/#/q/topic:bug/160211222:38
sridhar_ramtrozet: sripriya: do u see any *major* issues landing these two now..?22:38
sripriyasridhar_ram: not from my end, let me review the client patch now22:40
sridhar_ramsripriya: thanks!22:41
sripriyasridhar_ram: are we waiting for a new patch on the server side?22:49
sridhar_ramsripriya: hmm, yeah.. i don't see the unit tests yet..22:50
sripriyasridhar_ram: well we dont have one on client side too22:50
sridhar_ramsripriya: yeah, but client side is bit more urgent.. the release team term around time is long..22:51
sripriyasridhar_ram: ok will wait for a new patch then22:51
sridhar_ramsripriya: okay.. we can wait for unit test in server patch.. trozet need to keep that in the dependency for little longer22:52
sridhar_ramsripriya: I'll merge the client patchset now22:52
sripriyasridhar_ram: ack22:52
sridhar_rams3wong: ping22:56
s3wongsridhar_ram: pong22:56
*** bobh has joined #tacker22:57
sridhar_rams3wong: our client release deadline is approaching fast (just 3 more days left). I was wondering if you had a chance to try VNFFG plugin with your n-sfc driver ?22:57
s3wongsridhar_ram: running it? not yet...22:57
s3wongsridhar_ram: was the code approved?22:57
sridhar_rams3wong: just want to make sure the client changes (and the API) portion is functional end-2-end22:57
sridhar_rams3wong: not yet, but looks we are getting close, at least for the client changes..22:58
s3wongsridhar_ram: trozet has tested it against his code?22:58
sridhar_rams3wong: yes, i believe he tested it against a dummy ffg driver22:58
openstackgerritMerged openstack/python-tackerclient: Creates details API to fetch VNF detials  https://review.openstack.org/35405722:59
s3wongsridhar_ram: then I need to get his code also --- I haven't tested the integration with his code yet22:59
sridhar_rams3wong: it will be great if you can work w/ trozet to give this a spin ..23:00
s3wongsridhar_ram: I will give it a shot tonight... and will ping trozet (tomorrow) if I hit any problem23:01
sridhar_rams3wong: I'd like to avoid a scenario where the client release deadline passes with a FFG client / CLI in place but an end-2-end n-sfc port-pairs & classifiers are not punched in properly..23:01
sridhar_rams3wong: thanks a lot Stephen23:01
s3wongsridhar_ram: I would imagine that could only arise in plugin side bug23:02
s3wongsridhar_ram: Neutron port info is not part of client code anyway23:02
s3wongsridhar_ram: and the get_detail thing should do its job right (I would imagine)23:02
sridhar_rams3wong: true but we are introducing tons in the client / API side..a test w/ a FFG translating to a simple n-sfc chain create will increase the confidence ..23:04
sridhar_rams3wong: release-team deadline are cut-throat, learnt the hard way last time around (in Mitaka release)23:05
s3wongsridhar_ram: sure, will give it a spin ASAP23:05
sridhar_rams3wong: thanks!23:05
sridhar_ramtrozet: haiwei: next in the target merge list is https://review.openstack.org/#/c/341389 (VNFFG client).. do you see any *major* outstanding items to fix ?23:09
sridhar_ramsripriya: ^^^23:09
*** uck has joined #tacker23:13
*** bobh has quit IRC23:13
*** uck has quit IRC23:18
sripriyasridhar_ram: reviewing it currently, the only *major*  concern was the vnffd template attribute as a string instead of json23:22
sridhar_ramsripriya: ouch, that is a biggee..23:23
sripriyasridhar_ram: well it has impact on both server and client23:24
sridhar_ramsripriya: yes, and i meant.. it is ugly to let that be a string having known the impact23:25
sridhar_ramtrozet: ^^^23:25
sripriyasridhar_ram: left a comment on the patch, we can try to see if the impact is a lot. AFAIK, it should be fine to address this23:28
sridhar_ramsripriya: gr8, thanks23:29
*** xuhaiwei has joined #tacker23:31
*** prashantD__ has quit IRC23:37
*** prashantD__ has joined #tacker23:39
« Sunday, 2016-08-21 Index Tuesday, 2016-08-23 »

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