Wednesday, 2016-08-24

*** uck has quit IRC00:04
*** amotoki has joined #tacker00:05
*** amotoki has quit IRC00:10
*** Murali has quit IRC00:18
*** manikanta_tadi has quit IRC00:35
*** Murali has joined #tacker00:38
*** ftcjeff has joined #tacker00:39
*** ftcjeff has left #tacker00:40
dkushwahasripriya, ping00:49
sripriyadkushwaha: pong00:51
dkushwahasripriya, Currently I am working on https://bugs.launchpad.net/tacker/+bug/1570557 . It is working fine for direct input (i.e. name: vdu1-name)00:51
openstackLaunchpad bug 1570557 in tacker "RFE: Allow vdu (VM) names to be specified as a parameter" [Low,New] - Assigned to dharmendra (dharmendra-kushwaha)00:51
dkushwahasripriya, but getting stuck in name: {get_input : vdu1-name}00:51
dkushwahasripriya, can you please seggest where to handle this parameterized input.00:52
sripriyatrozet: ping00:53
sripriyadkushwaha: looking up00:54
*** manikanta_tadi has joined #tacker00:56
sripriyadkushwaha: refer https://github.com/openstack/tacker/blob/master/tacker/vm/infra_drivers/heat/heat.py#L32200:59
sripriyadkushwaha: the template needs to handle the name parameter similar to https://github.com/openstack/tacker/blob/master/tacker/tests/unit/vm/infra_drivers/heat/data/tosca_generic_vnfd_params.yaml01:00
sripriyadkushwaha: and then send the values in param file01:00
sripriyadkushwaha: does these pointers help?01:01
dkushwahasripriya, yes, it looks helpful. let me try with this.01:02
dkushwahasripriya, thank01:02
sripriyadkushwaha: np01:02
*** amotoki has joined #tacker01:06
*** amotoki has quit IRC01:10
*** vishwanathj has quit IRC01:11
*** sripriya has quit IRC01:39
*** s3wong has quit IRC01:43
*** sripriya has joined #tacker01:49
*** sripriya has quit IRC01:52
openstackgerritMerged openstack/tacker: Support purge of soft-deleted resources from DB tables  https://review.openstack.org/32965202:01
*** amotoki has joined #tacker02:06
*** Murali has quit IRC02:08
openstackgerritLu lei proposed openstack/python-tackerclient: Stop using mox from test_ssl/test_http.py  https://review.openstack.org/35913202:10
*** amotoki has quit IRC02:11
openstackgerritLu lei proposed openstack/python-tackerclient: Stop using mox from test_ssl/test_http.py  https://review.openstack.org/35913202:43
*** bobh has joined #tacker02:46
openstackgerritvishwanath jayaraman proposed openstack/tacker: Adds functional tests for common services plugin  https://review.openstack.org/35867802:55
openstackgerritqinchunhua proposed openstack/tacker: Python 3: dict.itervalues()  https://review.openstack.org/34629103:02
*** vishnoianil has quit IRC03:02
*** gongysh has joined #tacker03:03
gongyshsridhar_ram, hi03:04
gongyshsridhar_ram, https://review.openstack.org/#/c/352210/ is resolved,03:04
*** amotoki has joined #tacker03:07
*** amotoki has quit IRC03:11
*** vishwanathj has joined #tacker03:11
*** vishwanathj is now known as vishwanathj_zzz03:19
*** amotoki has joined #tacker03:24
*** bobh has quit IRC03:37
sridhar_ramgongysh: hi03:38
*** amotoki has quit IRC03:38
openstackgerritSridhar Ramaswamy proposed openstack/tacker: Device refactor Part2: Remove unused scheduler code  https://review.openstack.org/35221003:40
sridhar_ramgongysh: just rebased, will merge it after jenkins passes03:40
sridhar_ramgongysh: btw, not sure if you've looked at this.. http://lists.openstack.org/pipermail/openstack-dev/2016-August/102126.html03:41
sridhar_ramgongysh: folks are quite happy to about your contribution!03:42
openstackgerritdharmendra kushwaha proposed openstack/tacker: Allow vdu (VM) names to be specified as a parameter  https://review.openstack.org/35957603:44
openstackgerritdharmendra kushwaha proposed openstack/tacker: Allow vdu (VM) names to be specified as a parameter  https://review.openstack.org/35957603:46
gongyshsridhar_ram, thanks03:57
*** sripriya has joined #tacker03:57
gongyshsridhar_ram, it will force me to work harder03:57
*** gongysh has quit IRC03:59
*** amotoki has joined #tacker04:00
*** amotoki has quit IRC04:09
*** amotoki has joined #tacker04:10
*** jraju has joined #tacker04:14
*** jraju has quit IRC04:15
*** lulei has quit IRC04:17
*** amotoki has quit IRC04:31
dkushwahasripriya, hi04:32
sripriyadkushwaha: hello04:33
dkushwahasripriya, I have submitted  the patch for vm name in tosca: https://review.openstack.org/35957604:34
dkushwahasripriya, please review04:34
sripriyadkushwaha: cool, will review, may be delayed since client patchsets are priority for this week.04:35
*** neel has joined #tacker04:36
dkushwahasripriya, Thanks,  other than this, kindly have a quick look into https://review.openstack.org/#/c/346665/ . and please let me know if my approach is ok04:36
*** amotoki has joined #tacker04:37
*** manikanta_tadi has quit IRC04:38
*** alisha has joined #tacker04:38
sripriyadkushwaha: would it be better avoid monitor module call from plugin if vnf is in error state04:43
dkushwahasripriya, yes, make sense.04:45
dkushwahasripriya, thanks04:45
sripriyadkushwaha: db calls in monitor periodically can be an expensive operation04:45
sripriyadkushwaha: cool, there are may be other edge cases to handle such as tacker restart04:46
dkushwahasripriya, yes,  but even if we move this to plugin, we still needs to call db periodically04:47
dkushwahasripriya, isn't ?04:48
sripriyadkushwaha: wondering why we would need to do periodcally04:49
dkushwahasripriya, to get the current state?04:50
*** dkushwaha has left #tacker04:55
*** tbh has joined #tacker05:20
*** xuhaiwei has quit IRC05:37
openstackgerritzhangyanxian proposed openstack/tacker: Some obvious mistakes need to be fixed  https://review.openstack.org/35892205:37
*** mpsairam has quit IRC05:39
*** sripriya has quit IRC05:49
*** alisha has quit IRC05:55
openstackgerritMerged openstack/tacker: Updated from global requirements  https://review.openstack.org/35953006:00
*** alisha has joined #tacker06:04
*** neel has quit IRC06:06
openstackgerritvenkatamahesh proposed openstack/tacker: Clean up the imports according to hacking standards  https://review.openstack.org/35960806:08
*** xiayu has joined #tacker06:13
*** janki has joined #tacker06:15
xiayuvnf-update not work, i use noop mgmt_driver.06:16
xiayuif i update vnf with new config file, then tacker update the heat stack?06:19
*** mpsairam has joined #tacker06:19
*** lulei has joined #tacker06:20
xiayu@sridhar_ram06:20
sridhar_ramxiayu: noop driver is just a placeholder, it will not do anything06:22
*** neel has joined #tacker06:23
sridhar_ramxiayu: I'd suggest u to create a mgmt driver similar to OpenWRT for ur own vnf06:23
xiayui think the mgmt driver is used to config the nfv, but if i update the CP, VL info, it should call heat update stack api ..06:25
sridhar_ramxiayu: btw, VNF update is primarily used for config mgmt using thr mgmt driver than for heat stack update06:25
*** dkushwaha has joined #tacker06:33
openstackgerritLu lei proposed openstack/python-tackerclient: Stop using mox in tackerclient (1)  https://review.openstack.org/35913206:35
*** haiwei has joined #tacker06:41
jankisridhar_ram, ping06:45
openstackgerritvenkatamahesh proposed openstack/tacker: [DOC] Update the manual installation guide to rectify errors  https://review.openstack.org/35325806:46
*** manikanta_tadi has joined #tacker06:50
*** neel has quit IRC06:55
*** neel has joined #tacker07:08
*** santoshk has quit IRC07:09
*** tbh has quit IRC07:35
*** vishnoianil has joined #tacker07:35
*** diga has joined #tacker07:52
*** saju_m has joined #tacker07:59
*** amotoki has quit IRC08:01
*** vishnoianil has quit IRC08:09
*** vikasc has joined #tacker08:21
openstackgerritqinchunhua proposed openstack/tacker: Python 3: dict.itervalues()  https://review.openstack.org/34629108:22
*** saju_m has quit IRC08:26
*** saju_m has joined #tacker08:37
*** wsdwqe has joined #tacker08:44
wsdwqeटेस्टिंग हिंदी08:44
*** wsdwqe has quit IRC08:45
*** vikasc has left #tacker08:46
*** amotoki has joined #tacker09:09
*** amotoki has quit IRC09:17
*** manikanta_tadi has quit IRC09:19
*** manikanta_tadi has joined #tacker09:23
*** amotoki has joined #tacker09:26
*** lulei has quit IRC09:48
*** Murali_ has joined #tacker10:00
openstackgerritvenkatamahesh proposed openstack/tacker: Clean up the imports according to hacking standards  https://review.openstack.org/35960810:04
*** vikasc has joined #tacker10:11
*** tbh has joined #tacker10:28
*** Murali_ has quit IRC10:29
*** alisha has quit IRC10:30
*** neel has quit IRC10:31
*** alisha has joined #tacker10:43
*** diga has quit IRC11:02
openstackgerritvenkatamahesh proposed openstack/tacker: Clean up the imports according to hacking standards  https://review.openstack.org/35960811:16
openstackgerritLu lei proposed openstack/python-tackerclient: Stop using mox in tackerclient (2)  https://review.openstack.org/35981711:47
*** lulei has joined #tacker11:49
*** manikanta_tadi has quit IRC12:02
openstackgerritLu lei proposed openstack/python-tackerclient: Stop using mox in tackerclient (2)  https://review.openstack.org/35981712:03
*** alisha has quit IRC12:17
openstackgerritLu lei proposed openstack/python-tackerclient: Stop using mox in tackerclient (2)  https://review.openstack.org/35981712:17
*** diga has joined #tacker12:20
*** trozet has quit IRC12:28
*** trozet has joined #tacker12:43
*** KanagarajM has joined #tacker12:43
*** diga_ has joined #tacker12:48
*** diga has quit IRC12:49
openstackgerritLu lei proposed openstack/python-tackerclient: Stop using mox in tackerclient (2)  https://review.openstack.org/35981712:50
*** bobh has joined #tacker12:52
*** saju_m has quit IRC12:56
*** vishwanathj_zzz is now known as vishwanthj13:03
*** diga_ has quit IRC13:04
*** saju_m has joined #tacker13:08
*** bobh has quit IRC13:11
*** diga has joined #tacker13:19
*** openstackgerrit has quit IRC13:26
*** openstackgerrit has joined #tacker13:27
openstackgerritvenkatamahesh proposed openstack/tacker: Clean up the imports according to hacking standards  https://review.openstack.org/35960813:27
*** amotoki has quit IRC13:29
*** trozet has quit IRC13:40
*** amotoki has joined #tacker13:44
*** bobh has joined #tacker13:45
*** KanagarajM has quit IRC13:46
*** bobh_ has joined #tacker13:53
*** bobh has quit IRC13:57
*** KanagarajM has joined #tacker14:00
*** amotoki has quit IRC14:02
*** amotoki has joined #tacker14:22
*** amotoki has quit IRC14:36
openstackgerritJanki Chhatbar proposed openstack/tacker: Add VNF resource details to get vnf API  https://review.openstack.org/34083814:43
*** amotoki has joined #tacker14:50
*** bobh_ has quit IRC15:01
openstackgerritJanki Chhatbar proposed openstack/python-tackerclient: Add vnfd_template argument for creating vnf  https://review.openstack.org/35915615:03
*** janki has quit IRC15:05
*** saju_m has quit IRC15:13
*** janki has joined #tacker15:22
*** diga has quit IRC15:36
*** trozet has joined #tacker15:43
*** uck has joined #tacker15:53
*** vishwanthj has quit IRC15:56
*** bobh has joined #tacker16:02
*** bobh has quit IRC16:06
trozetsridhar_ram: ping?16:20
*** neel has joined #tacker16:21
sridhar_ramtrozet: hi16:21
trozetsridhar_ram: i would like to understand more about https://review.openstack.org/#/c/340838/24/tacker/vm/plugin.py16:22
trozetsridhar_ram: when you do a get_vnfs(), in the plugin method, you don't add the 'vnfs' key and make into a dict, right?  That is done by the REST reply by the extension?16:23
* sridhar_ram looking up16:23
trozetsridhar_ram: for example, if i do get_vnfs()  in the plugin, I should get back [ {'vnf_id': <id>, 'vnf_name': 'blah'},..]16:24
trozetsridhar_ram: not {'vnfs':  [ {'vnf_id': <id>, 'vnf_name': 'blah'},..]}16:24
trozetsridhar_ram: I think the encapsulation into a dictionary with 'vnfs' is done by a higher layer than the plugin, but looking for you to confirm/deny that16:25
*** KanagarajM has quit IRC16:25
sridhar_ramtrozet: my understanding is this is taken care in the higher wsgi layer, not in the plugin.16:26
trozetsridhar_ram: right, ok so we agree on that point16:26
trozetsridhar_ram: so then my next question becomes, why in the link above, do we need to add "resources" and transform it into a dict, shouldn't by the same logic, that be handled by the WSGI layer?16:27
sridhar_ramtrozet: sripriya is the expert in that piece of code..16:27
trozetsridhar_ram: yeah she's not online, so I figured I would ask you16:28
jankisridhar_ram, trozet: "resources" is added to match with the SUB_ATTRIBUTE_MAP16:28
* sridhar_ram slow response as I'm in my mobile phone16:29
jankisridhar_ram, trozet: about being it a list, WSGI layer expects it to be a list beacuse this is a "LIST" operation16:30
jankihad it been a "SHOW" operation, dict would be approriate16:30
jankithis is what discussion I had with sripriya few days back16:31
trozetjanki, sridhar_ram: I see, resources is an attribute, not the REST resource itself.  I think the resources attribute should be handled by the driver16:31
trozetjanki, sridhar_ram: then you can have a real list of resources, rather than this fake encap16:31
jankitrozet, heat replies with a dict and hence need to encapsulate it to list this way16:32
sridhar_ramtrozet: also, we are also following some pattern here, similar to heat16:32
trozetjanki, sridhar_ram: yeah my suggestion is to return a list from heat16:32
sridhar_ramhttp://developer.openstack.org/api-ref-orchestration-v1.html16:33
jankitrozet, you mean to convert it to list in heat.py rather than doing it here?16:33
trozetjanki, sridhar_ram: then in the plugin or whatever you can convert each item in the list to a dictionary prepended with 'resource' and change the extension from 'resources' to 'resource'16:34
sridhar_ramtrozet: no, we can't directly return the list from heat...we can't let infra-driver things "leak" up into plugin layer16:34
sridhar_ramtrozet: janki: sorry, gottu run here16:35
trozetsridhar_ram: why though? what makes you have to use a dict?16:35
jankisridhar_ram, please ping me once you are back. need to talk about vnf-template spec16:35
jankitrozet, heat get-resources api is called which returns a dict. this dict is {'VDU1': {type: " ", uuid: ' '}, CP1: {type: ' ', uuid: ' '}}16:37
jankitrozet, for all VNF nodes, its type and uuid16:38
jankiadded resource due to sub_attribute_map and list for the above mentioned reason16:39
trozetjanki: https://paste.fedoraproject.org/413438/16:39
*** vishnoianil has joined #tacker16:40
jankitrozet, how would this come out on the client side? I mean how to write it in attribute map and also the number of "resource" will vary from template to template16:42
trozetjanki: just take a look at how list vnfs works16:43
trozetjanki: its the exact same thing, except its just vnf_id:16:43
jankitrozet, secondly, this dict too needs to constructed explictly. there is no way we can make heat return data in the expected format16:43
jankitrozet, looking16:44
trozetjanki: yeah, heat driver can just stay as is, and you can parse it into this format in the plugin16:45
trozetjanki: let me post it in the comments on the review, so sripriya can see it16:45
jankitrozet, sure.16:46
*** alisha has joined #tacker16:50
*** vishwanathj has joined #tacker16:52
*** janki has quit IRC16:59
*** bobh has joined #tacker17:02
*** prashantD has joined #tacker17:05
*** bobh has quit IRC17:08
*** bobh has joined #tacker17:09
*** neel has quit IRC17:25
*** neel has joined #tacker17:30
*** vishnoianil has quit IRC17:30
*** sripriya has joined #tacker17:37
trozethi sripriya17:39
sripriyatrozet: hello17:39
trozetsripriya: i was discussing with janki and sridhar_ram  before you came online about the get vnf resource detail stuff, I left a comment on the patch, can we discuss it here?17:40
*** alisha has quit IRC17:40
sripriyatrozet: looking up17:42
sripriyatrozet: just caught up17:44
trozetsripriya: cool, what do you think?17:44
sripriyatrozet: are you pointing to returning as {‘resource’: {}. ‘resource’: {},..}17:44
sripriyatrozet: i mean  [‘resource’: {}. ‘resource’: {},..]17:44
trozetsripriya: like this https://paste.fedoraproject.org/413445/17:45
trozet[{'resource': 'CP11', 'id': <id>, 'type': 'NeutronPort'}, {'resource': 'CP12', 'id': <id>, 'type': 'NeutronPort'}]17:45
sripriyatrozet: that means make resource as the subresource for vnfs like: /vnfs/<uuid>/resources?17:46
sripriyatrozet: btw the response in above link  should be : {‘resources’: [{}, {},…}17:46
sripriyatrozet: corresponding to the wsgi layer17:47
trozetsripriya: i think its more like this /vnfs/uuid/detail/<resource>17:47
trozet<uuid>*17:47
trozetsripriya: similar to how vnfs is /vnfs/<id>17:48
trozets/detail/details/17:48
sripriyatrozet: hmm, not sure how <resource> uniquely identifies as in individual ‘detail’ here,17:49
sripriyatrozet: this is equivalent to detail<—>resource17:49
sripriyatrozet: tacker should deal with its own resources, not bring a lower layer resource name on to the API layer17:51
trozetsripriya: well the <resource> in this case is really VNFD  resource name17:52
trozetsripriya: ideally you would want to use an ID, but this is OK i think17:52
trozetsripriya: i dont think it is a lower layer resource name, because the name is defined in VNFD, which is a tacker/tosca concept17:52
sripriyatrozet: this is just wrapping heat’s api to the tacker something like http://developer.openstack.org/api-ref-orchestration-v1.html#stack-resources17:53
sripriyatrozet: what i see here is details sub resource of vnf is always going to imply it should return an infra layer resource information17:54
trozetsripriya: well isn't that he point of this patch :) ?17:55
sripriyatrozet: if i need to evolve my details subresource to return more detailed info other than resources, should i create a new subresource then?17:55
sripriyatrozet: you would rather call the heat client api itself directly to fetch the instance_id resources :-)17:55
sripriyatrozet: the concern is here to keep it generic17:56
sripriyatrozet: at the plugin level17:56
sripriyatrozet: if it is only limiting to fetching resource info , then why have it as ‘details’ ?17:57
trozetsripriya: that's a good point, it probably should be s/details/resources, and the attribute should be 'resource_id' or 'resource_name'17:58
trozetso /vnfs/<id>/resources/<id>17:58
sripriyatrozet: yes, well it is our call how we want to do this17:59
trozetso you could have resources as the rest extension, then id, name, type as the attributes18:00
trozetsripriya: then the only confining detail there is you are expecting all VNFM driver to give you back id,name, and type of resources created18:00
sripriyatrozet: if we think ‘resources’ is justifiable to be brought up as a sub resource of the vnf , we can modify the url18:00
sripriyatrozet: that is where i was coming to18:00
sripriyatrozet: does this apply to all infra drivers?18:01
trozetsripriya: but I think that restriction is better than the current approach18:01
trozetsripriya: what are the other drivers, just nova?18:01
sripriyatrozet: beyond openstack may be?18:01
trozetsripriya: yeah like aws or something...no idea, but i think, name,id,type are pretty low requirements for hte driver18:02
sripriyatrozet: i’m fine to modify /s/details/resources unless we have some other good reason to not expose it is a subresource of vnfs18:05
sripriyasridhar_ram: ^18:05
trozetsripriya: ok great.  Then we could also have get_vnf_resource() and get a single resource id,type,name18:06
sripriyatrozet: we need to finalize this since this has a client impact18:07
*** bobh has quit IRC18:08
sripriyatrozet: then i assume we introduce a new command on the client side18:08
trozetsripriya: yeah18:08
sripriyatrozet: tacker vnf-resources show ??18:09
trozetsripriya: yeah makes sense, and vnf-resources-list18:09
trozetsripriya: do you have a link to the client patch janki is working on?18:09
sripriyatrozet: that is already merged i believe18:10
trozetsripriya: ah18:10
sripriyatrozet: this has significant change/deviation from the current patch18:16
*** amotoki has quit IRC18:17
trozetsripriya: yeah, cant we fix the client though as a bug? even after freeze?18:17
sripriyatrozet: like introducing a new set of commands? :)18:17
trozetsripriya: haha :)18:18
trozetsripriya: just fixing the current cmd ;)18:18
trozetsripriya: if you want I don't mind writing the patch now18:18
sripriyatrozet: there was no impact at all on current cmds ;)18:18
sripriyatrozet: i think that would be better18:19
sripriyatrozet: we can get the review soon and try to merge18:19
sripriyatrozet; but i would wait for sridhar_ram to waive us a green flag18:19
trozetsripriya: oh so there was no new command introduced? it is just part of vnf-show?18:19
sripriyatrozet: yup18:19
trozetsripriya: ah ok18:19
*** vishnoianil has joined #tacker18:23
*** vishwanathj has quit IRC18:25
*** vishwanathj has joined #tacker18:26
*** tbh has quit IRC18:29
sripriyatrozet: to fetch an individual resource are you going to pass the resource name?18:29
trozetsripriya: well I guess the first question is, are we able to label a sub resource attribute as primary?18:32
trozetsripriya: if yes, then we should probably follow other tacker convention, and make the id the primary key18:33
sripriyatrozet: we do not store this info  in db18:33
sripriyatrozet: my question is related to what uniquely identifies the resource?18:33
trozetsripriya: i think ID, does 'primary_key' in the extension refer to db?18:34
trozetsripriya: i thought it referred to the primary key used in the rest resource query18:34
sripriyatrozet: that is what i understand, was trying to look up how the validation happens18:38
trozetsripriya: ok, i'm not sure how it works. But i would think we want resource: -id to be primary key, since other REST resources seem to always use id as the primary key18:39
sripriyatrozet: but resource id is something you only get from resources list with current implemenatation18:41
sripriyatrozet: fyi for the validation piece https://github.com/openstack/tacker/blob/master/tacker/api/v1/base.py#L26018:41
sripriyatrozet: need not be on the id, but that is the typical attribute used as a primary key18:41
trozetsripriya: ok then if we can, name would be better, since we know the name from the VNFD18:41
sripriyatrozet: my only concern is with ‘resources’ uniqueness passed on to the lower layers (infra drivers) and expecting them to have unique resource names inside the vnf18:42
sripriyatrozet: this is not under the control of tacker18:43
trozetsripriya: yeah18:43
sripriyatrozet: tacker is not guaranteeing that resources is goign to be unique even though it is a suresource of vnf and tacker is expected to handle the uniqueness18:43
trozetsripriya: it is more plausible that the ID will be unique than a name18:44
trozetmore unique*18:44
sripriyatrozet: we are then enforcing ’id’ on resource which infra driver is expected to handle?18:45
trozetsripriya: i think that is an OK expectation.  If the infra_driver doesn't support creating sub-resources with IDs, it can simply return not implemented18:47
sripriyatrozet: so resources will have attributes id, name and type18:49
trozetsripriya: right18:49
sripriyatrozet: resource show in heat is done based on resource name http://developer.openstack.org/api-ref-orchestration-v1.html#stack-resources18:50
openstackgerritTim Rozet proposed openstack/python-tackerclient: Add client support for VNFFG in NFVO  https://review.openstack.org/34138918:51
trozetsripriya: ah18:51
trozetsripriya: so then are we OK with using name as primary_key and expecting it to be unique for other drivers?18:51
sripriyatrozet: i dont know what qualifies as correct implementation with these challenges/ exceptions. i guess we can go with this assumption18:52
trozetsripriya: yeah we could always change it later if support for a different VIM comes along and we need to tweak it18:54
sripriyatrozet: yes18:55
*** bobh has joined #tacker18:55
openstackgerritvishwanath jayaraman proposed openstack/tacker: Adds functional tests for common services plugin  https://review.openstack.org/35867818:56
*** uck has quit IRC19:04
*** uck has joined #tacker19:05
trozetsripriya: coming up with a client patch now19:07
*** uck has quit IRC19:09
*** sripriya has quit IRC19:21
*** neel has quit IRC19:23
*** saju_m has joined #tacker19:23
sridhar_ramtrozet: ping19:51
trozetsridhar_ram: hello19:51
sridhar_ramtrozet: just caught up on this discussion..19:53
*** sripriya has joined #tacker19:54
trozetsridhar_ram: yeah it was a good one i think19:54
sridhar_ramtrozet: using vnf-resource-list seems fine.. basically we ditch --details instead use a separate command19:54
sridhar_ramtrozet: now, on the api it shd be .. /vnf/<uuid>/resources .. correct ?19:54
trozetsridhar_ram: right19:54
trozetwell19:55
trozetsridhar_ram: /vnf/<id>/resource/<id>19:55
trozetsridhar_ram: sorry forgot we agreed on name as the primary_key19:55
sridhar_ramtrozet: well, that is a further add-on.. it is optional for now19:55
trozetsridhar_ram: so /vnf/<id>/resource/<name>19:55
trozetsridhar_ram: yah19:56
sridhar_ramtrozet: for your vnffg needs /vnd/<id>/resoures should be sufficient19:56
trozetsridhar_ram: sure19:56
sridhar_ramtrozet: okay.. here is a paste ..19:56
sridhar_ramtrozet: http://paste.openstack.org/show/563124/19:56
sridhar_ramtrozet: L9 & L1219:57
sridhar_ramtrozet: make sense?19:57
trozetsridhar_ram: exactly19:57
*** s3wong has joined #tacker19:58
sridhar_ramtrozet: okay.. let's proceed then..20:00
sridhar_ramtrozet: IMO, /vnf/<id>/resource/<id> is a nice to have :)20:00
sridhar_ramtrozet: i'm telling mostly from timeline point of view.. the deadline is upon us to wrap up tackerclient20:01
trozetsridhar_ram: ok I'm writing a patch now, if it seems simple enough then I will add it otherwise i wont if it takes too much time20:02
sripriyatrozet: ack20:04
*** uck has joined #tacker20:06
sridhar_ramtrozet: sounds good..20:11
*** uck has quit IRC20:12
openstackgerritMerged openstack/tacker: Device refactor Part2: Remove unused scheduler code  https://review.openstack.org/35221020:16
*** xiayu has quit IRC20:23
*** xiayu has joined #tacker20:25
sridhar_ramtrozet: btw, this along means we need to revert the changes that went into for --details .. https://review.openstack.org/#/c/354057/20:26
openstackgerritMerged openstack/tacker: Python 3: dict.itervalues()  https://review.openstack.org/34629120:33
sridhar_ramsripriya: bobh: do you folks see any issues with https://review.openstack.org/#/c/330318/ ?20:45
sridhar_ramsripriya: bobh: fyi, the server side is still in progress https://review.openstack.org/#/c/331039/ ..  but it will be nice to merge the client before the newton release deadline20:46
sripriyasridhar_ram: i dont see any issues with the client, i think it is good to go20:53
sridhar_ramsripriya: thanks a lot for looking into it20:53
sripriyasridhar_ram: np20:54
openstackgerritMerged openstack/python-tackerclient: Add "Description" parameter while creating VNF with CLI.  https://review.openstack.org/33031821:03
*** bobh has quit IRC21:33
*** santoshk has joined #tacker21:37
*** sripriya has quit IRC21:52
*** vishwanathj has quit IRC22:02
*** uck has joined #tacker22:09
*** uck has quit IRC22:14
*** sripriya has joined #tacker22:36
*** ksantoshk has joined #tacker23:32
*** KanagarajM has joined #tacker23:36
*** saju_m has quit IRC23:42

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