*** uck has quit IRC | 00:04 | |
*** amotoki has joined #tacker | 00:05 | |
*** amotoki has quit IRC | 00:10 | |
*** Murali has quit IRC | 00:18 | |
*** manikanta_tadi has quit IRC | 00:35 | |
*** Murali has joined #tacker | 00:38 | |
*** ftcjeff has joined #tacker | 00:39 | |
*** ftcjeff has left #tacker | 00:40 | |
dkushwaha | sripriya, ping | 00:49 |
---|---|---|
sripriya | dkushwaha: pong | 00:51 |
dkushwaha | sripriya, 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 |
openstack | Launchpad bug 1570557 in tacker "RFE: Allow vdu (VM) names to be specified as a parameter" [Low,New] - Assigned to dharmendra (dharmendra-kushwaha) | 00:51 |
dkushwaha | sripriya, but getting stuck in name: {get_input : vdu1-name} | 00:51 |
dkushwaha | sripriya, can you please seggest where to handle this parameterized input. | 00:52 |
sripriya | trozet: ping | 00:53 |
sripriya | dkushwaha: looking up | 00:54 |
*** manikanta_tadi has joined #tacker | 00:56 | |
sripriya | dkushwaha: refer https://github.com/openstack/tacker/blob/master/tacker/vm/infra_drivers/heat/heat.py#L322 | 00:59 |
sripriya | dkushwaha: 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.yaml | 01:00 |
sripriya | dkushwaha: and then send the values in param file | 01:00 |
sripriya | dkushwaha: does these pointers help? | 01:01 |
dkushwaha | sripriya, yes, it looks helpful. let me try with this. | 01:02 |
dkushwaha | sripriya, thank | 01:02 |
sripriya | dkushwaha: np | 01:02 |
*** amotoki has joined #tacker | 01:06 | |
*** amotoki has quit IRC | 01:10 | |
*** vishwanathj has quit IRC | 01:11 | |
*** sripriya has quit IRC | 01:39 | |
*** s3wong has quit IRC | 01:43 | |
*** sripriya has joined #tacker | 01:49 | |
*** sripriya has quit IRC | 01:52 | |
openstackgerrit | Merged openstack/tacker: Support purge of soft-deleted resources from DB tables https://review.openstack.org/329652 | 02:01 |
*** amotoki has joined #tacker | 02:06 | |
*** Murali has quit IRC | 02:08 | |
openstackgerrit | Lu lei proposed openstack/python-tackerclient: Stop using mox from test_ssl/test_http.py https://review.openstack.org/359132 | 02:10 |
*** amotoki has quit IRC | 02:11 | |
openstackgerrit | Lu lei proposed openstack/python-tackerclient: Stop using mox from test_ssl/test_http.py https://review.openstack.org/359132 | 02:43 |
*** bobh has joined #tacker | 02:46 | |
openstackgerrit | vishwanath jayaraman proposed openstack/tacker: Adds functional tests for common services plugin https://review.openstack.org/358678 | 02:55 |
openstackgerrit | qinchunhua proposed openstack/tacker: Python 3: dict.itervalues() https://review.openstack.org/346291 | 03:02 |
*** vishnoianil has quit IRC | 03:02 | |
*** gongysh has joined #tacker | 03:03 | |
gongysh | sridhar_ram, hi | 03:04 |
gongysh | sridhar_ram, https://review.openstack.org/#/c/352210/ is resolved, | 03:04 |
*** amotoki has joined #tacker | 03:07 | |
*** amotoki has quit IRC | 03:11 | |
*** vishwanathj has joined #tacker | 03:11 | |
*** vishwanathj is now known as vishwanathj_zzz | 03:19 | |
*** amotoki has joined #tacker | 03:24 | |
*** bobh has quit IRC | 03:37 | |
sridhar_ram | gongysh: hi | 03:38 |
*** amotoki has quit IRC | 03:38 | |
openstackgerrit | Sridhar Ramaswamy proposed openstack/tacker: Device refactor Part2: Remove unused scheduler code https://review.openstack.org/352210 | 03:40 |
sridhar_ram | gongysh: just rebased, will merge it after jenkins passes | 03:40 |
sridhar_ram | gongysh: btw, not sure if you've looked at this.. http://lists.openstack.org/pipermail/openstack-dev/2016-August/102126.html | 03:41 |
sridhar_ram | gongysh: folks are quite happy to about your contribution! | 03:42 |
openstackgerrit | dharmendra kushwaha proposed openstack/tacker: Allow vdu (VM) names to be specified as a parameter https://review.openstack.org/359576 | 03:44 |
openstackgerrit | dharmendra kushwaha proposed openstack/tacker: Allow vdu (VM) names to be specified as a parameter https://review.openstack.org/359576 | 03:46 |
gongysh | sridhar_ram, thanks | 03:57 |
*** sripriya has joined #tacker | 03:57 | |
gongysh | sridhar_ram, it will force me to work harder | 03:57 |
*** gongysh has quit IRC | 03:59 | |
*** amotoki has joined #tacker | 04:00 | |
*** amotoki has quit IRC | 04:09 | |
*** amotoki has joined #tacker | 04:10 | |
*** jraju has joined #tacker | 04:14 | |
*** jraju has quit IRC | 04:15 | |
*** lulei has quit IRC | 04:17 | |
*** amotoki has quit IRC | 04:31 | |
dkushwaha | sripriya, hi | 04:32 |
sripriya | dkushwaha: hello | 04:33 |
dkushwaha | sripriya, I have submitted the patch for vm name in tosca: https://review.openstack.org/359576 | 04:34 |
dkushwaha | sripriya, please review | 04:34 |
sripriya | dkushwaha: cool, will review, may be delayed since client patchsets are priority for this week. | 04:35 |
*** neel has joined #tacker | 04:36 | |
dkushwaha | sripriya, 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 ok | 04:36 |
*** amotoki has joined #tacker | 04:37 | |
*** manikanta_tadi has quit IRC | 04:38 | |
*** alisha has joined #tacker | 04:38 | |
sripriya | dkushwaha: would it be better avoid monitor module call from plugin if vnf is in error state | 04:43 |
dkushwaha | sripriya, yes, make sense. | 04:45 |
dkushwaha | sripriya, thanks | 04:45 |
sripriya | dkushwaha: db calls in monitor periodically can be an expensive operation | 04:45 |
sripriya | dkushwaha: cool, there are may be other edge cases to handle such as tacker restart | 04:46 |
dkushwaha | sripriya, yes, but even if we move this to plugin, we still needs to call db periodically | 04:47 |
dkushwaha | sripriya, isn't ? | 04:48 |
sripriya | dkushwaha: wondering why we would need to do periodcally | 04:49 |
dkushwaha | sripriya, to get the current state? | 04:50 |
*** dkushwaha has left #tacker | 04:55 | |
*** tbh has joined #tacker | 05:20 | |
*** xuhaiwei has quit IRC | 05:37 | |
openstackgerrit | zhangyanxian proposed openstack/tacker: Some obvious mistakes need to be fixed https://review.openstack.org/358922 | 05:37 |
*** mpsairam has quit IRC | 05:39 | |
*** sripriya has quit IRC | 05:49 | |
*** alisha has quit IRC | 05:55 | |
openstackgerrit | Merged openstack/tacker: Updated from global requirements https://review.openstack.org/359530 | 06:00 |
*** alisha has joined #tacker | 06:04 | |
*** neel has quit IRC | 06:06 | |
openstackgerrit | venkatamahesh proposed openstack/tacker: Clean up the imports according to hacking standards https://review.openstack.org/359608 | 06:08 |
*** xiayu has joined #tacker | 06:13 | |
*** janki has joined #tacker | 06:15 | |
xiayu | vnf-update not work, i use noop mgmt_driver. | 06:16 |
xiayu | if i update vnf with new config file, then tacker update the heat stack? | 06:19 |
*** mpsairam has joined #tacker | 06:19 | |
*** lulei has joined #tacker | 06:20 | |
xiayu | @sridhar_ram | 06:20 |
sridhar_ram | xiayu: noop driver is just a placeholder, it will not do anything | 06:22 |
*** neel has joined #tacker | 06:23 | |
sridhar_ram | xiayu: I'd suggest u to create a mgmt driver similar to OpenWRT for ur own vnf | 06:23 |
xiayu | i 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_ram | xiayu: btw, VNF update is primarily used for config mgmt using thr mgmt driver than for heat stack update | 06:25 |
*** dkushwaha has joined #tacker | 06:33 | |
openstackgerrit | Lu lei proposed openstack/python-tackerclient: Stop using mox in tackerclient (1) https://review.openstack.org/359132 | 06:35 |
*** haiwei has joined #tacker | 06:41 | |
janki | sridhar_ram, ping | 06:45 |
openstackgerrit | venkatamahesh proposed openstack/tacker: [DOC] Update the manual installation guide to rectify errors https://review.openstack.org/353258 | 06:46 |
*** manikanta_tadi has joined #tacker | 06:50 | |
*** neel has quit IRC | 06:55 | |
*** neel has joined #tacker | 07:08 | |
*** santoshk has quit IRC | 07:09 | |
*** tbh has quit IRC | 07:35 | |
*** vishnoianil has joined #tacker | 07:35 | |
*** diga has joined #tacker | 07:52 | |
*** saju_m has joined #tacker | 07:59 | |
*** amotoki has quit IRC | 08:01 | |
*** vishnoianil has quit IRC | 08:09 | |
*** vikasc has joined #tacker | 08:21 | |
openstackgerrit | qinchunhua proposed openstack/tacker: Python 3: dict.itervalues() https://review.openstack.org/346291 | 08:22 |
*** saju_m has quit IRC | 08:26 | |
*** saju_m has joined #tacker | 08:37 | |
*** wsdwqe has joined #tacker | 08:44 | |
wsdwqe | टेस्टिंग हिंदी | 08:44 |
*** wsdwqe has quit IRC | 08:45 | |
*** vikasc has left #tacker | 08:46 | |
*** amotoki has joined #tacker | 09:09 | |
*** amotoki has quit IRC | 09:17 | |
*** manikanta_tadi has quit IRC | 09:19 | |
*** manikanta_tadi has joined #tacker | 09:23 | |
*** amotoki has joined #tacker | 09:26 | |
*** lulei has quit IRC | 09:48 | |
*** Murali_ has joined #tacker | 10:00 | |
openstackgerrit | venkatamahesh proposed openstack/tacker: Clean up the imports according to hacking standards https://review.openstack.org/359608 | 10:04 |
*** vikasc has joined #tacker | 10:11 | |
*** tbh has joined #tacker | 10:28 | |
*** Murali_ has quit IRC | 10:29 | |
*** alisha has quit IRC | 10:30 | |
*** neel has quit IRC | 10:31 | |
*** alisha has joined #tacker | 10:43 | |
*** diga has quit IRC | 11:02 | |
openstackgerrit | venkatamahesh proposed openstack/tacker: Clean up the imports according to hacking standards https://review.openstack.org/359608 | 11:16 |
openstackgerrit | Lu lei proposed openstack/python-tackerclient: Stop using mox in tackerclient (2) https://review.openstack.org/359817 | 11:47 |
*** lulei has joined #tacker | 11:49 | |
*** manikanta_tadi has quit IRC | 12:02 | |
openstackgerrit | Lu lei proposed openstack/python-tackerclient: Stop using mox in tackerclient (2) https://review.openstack.org/359817 | 12:03 |
*** alisha has quit IRC | 12:17 | |
openstackgerrit | Lu lei proposed openstack/python-tackerclient: Stop using mox in tackerclient (2) https://review.openstack.org/359817 | 12:17 |
*** diga has joined #tacker | 12:20 | |
*** trozet has quit IRC | 12:28 | |
*** trozet has joined #tacker | 12:43 | |
*** KanagarajM has joined #tacker | 12:43 | |
*** diga_ has joined #tacker | 12:48 | |
*** diga has quit IRC | 12:49 | |
openstackgerrit | Lu lei proposed openstack/python-tackerclient: Stop using mox in tackerclient (2) https://review.openstack.org/359817 | 12:50 |
*** bobh has joined #tacker | 12:52 | |
*** saju_m has quit IRC | 12:56 | |
*** vishwanathj_zzz is now known as vishwanthj | 13:03 | |
*** diga_ has quit IRC | 13:04 | |
*** saju_m has joined #tacker | 13:08 | |
*** bobh has quit IRC | 13:11 | |
*** diga has joined #tacker | 13:19 | |
*** openstackgerrit has quit IRC | 13:26 | |
*** openstackgerrit has joined #tacker | 13:27 | |
openstackgerrit | venkatamahesh proposed openstack/tacker: Clean up the imports according to hacking standards https://review.openstack.org/359608 | 13:27 |
*** amotoki has quit IRC | 13:29 | |
*** trozet has quit IRC | 13:40 | |
*** amotoki has joined #tacker | 13:44 | |
*** bobh has joined #tacker | 13:45 | |
*** KanagarajM has quit IRC | 13:46 | |
*** bobh_ has joined #tacker | 13:53 | |
*** bobh has quit IRC | 13:57 | |
*** KanagarajM has joined #tacker | 14:00 | |
*** amotoki has quit IRC | 14:02 | |
*** amotoki has joined #tacker | 14:22 | |
*** amotoki has quit IRC | 14:36 | |
openstackgerrit | Janki Chhatbar proposed openstack/tacker: Add VNF resource details to get vnf API https://review.openstack.org/340838 | 14:43 |
*** amotoki has joined #tacker | 14:50 | |
*** bobh_ has quit IRC | 15:01 | |
openstackgerrit | Janki Chhatbar proposed openstack/python-tackerclient: Add vnfd_template argument for creating vnf https://review.openstack.org/359156 | 15:03 |
*** janki has quit IRC | 15:05 | |
*** saju_m has quit IRC | 15:13 | |
*** janki has joined #tacker | 15:22 | |
*** diga has quit IRC | 15:36 | |
*** trozet has joined #tacker | 15:43 | |
*** uck has joined #tacker | 15:53 | |
*** vishwanthj has quit IRC | 15:56 | |
*** bobh has joined #tacker | 16:02 | |
*** bobh has quit IRC | 16:06 | |
trozet | sridhar_ram: ping? | 16:20 |
*** neel has joined #tacker | 16:21 | |
sridhar_ram | trozet: hi | 16:21 |
trozet | sridhar_ram: i would like to understand more about https://review.openstack.org/#/c/340838/24/tacker/vm/plugin.py | 16:22 |
trozet | sridhar_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 up | 16:23 | |
trozet | sridhar_ram: for example, if i do get_vnfs() in the plugin, I should get back [ {'vnf_id': <id>, 'vnf_name': 'blah'},..] | 16:24 |
trozet | sridhar_ram: not {'vnfs': [ {'vnf_id': <id>, 'vnf_name': 'blah'},..]} | 16:24 |
trozet | sridhar_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 that | 16:25 |
*** KanagarajM has quit IRC | 16:25 | |
sridhar_ram | trozet: my understanding is this is taken care in the higher wsgi layer, not in the plugin. | 16:26 |
trozet | sridhar_ram: right, ok so we agree on that point | 16:26 |
trozet | sridhar_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_ram | trozet: sripriya is the expert in that piece of code.. | 16:27 |
trozet | sridhar_ram: yeah she's not online, so I figured I would ask you | 16:28 |
janki | sridhar_ram, trozet: "resources" is added to match with the SUB_ATTRIBUTE_MAP | 16:28 |
* sridhar_ram slow response as I'm in my mobile phone | 16:29 | |
janki | sridhar_ram, trozet: about being it a list, WSGI layer expects it to be a list beacuse this is a "LIST" operation | 16:30 |
janki | had it been a "SHOW" operation, dict would be approriate | 16:30 |
janki | this is what discussion I had with sripriya few days back | 16:31 |
trozet | janki, sridhar_ram: I see, resources is an attribute, not the REST resource itself. I think the resources attribute should be handled by the driver | 16:31 |
trozet | janki, sridhar_ram: then you can have a real list of resources, rather than this fake encap | 16:31 |
janki | trozet, heat replies with a dict and hence need to encapsulate it to list this way | 16:32 |
sridhar_ram | trozet: also, we are also following some pattern here, similar to heat | 16:32 |
trozet | janki, sridhar_ram: yeah my suggestion is to return a list from heat | 16:32 |
sridhar_ram | http://developer.openstack.org/api-ref-orchestration-v1.html | 16:33 |
janki | trozet, you mean to convert it to list in heat.py rather than doing it here? | 16:33 |
trozet | janki, 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_ram | trozet: no, we can't directly return the list from heat...we can't let infra-driver things "leak" up into plugin layer | 16:34 |
sridhar_ram | trozet: janki: sorry, gottu run here | 16:35 |
trozet | sridhar_ram: why though? what makes you have to use a dict? | 16:35 |
janki | sridhar_ram, please ping me once you are back. need to talk about vnf-template spec | 16:35 |
janki | trozet, heat get-resources api is called which returns a dict. this dict is {'VDU1': {type: " ", uuid: ' '}, CP1: {type: ' ', uuid: ' '}} | 16:37 |
janki | trozet, for all VNF nodes, its type and uuid | 16:38 |
janki | added resource due to sub_attribute_map and list for the above mentioned reason | 16:39 |
trozet | janki: https://paste.fedoraproject.org/413438/ | 16:39 |
*** vishnoianil has joined #tacker | 16:40 | |
janki | trozet, 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 template | 16:42 |
trozet | janki: just take a look at how list vnfs works | 16:43 |
trozet | janki: its the exact same thing, except its just vnf_id: | 16:43 |
janki | trozet, secondly, this dict too needs to constructed explictly. there is no way we can make heat return data in the expected format | 16:43 |
janki | trozet, looking | 16:44 |
trozet | janki: yeah, heat driver can just stay as is, and you can parse it into this format in the plugin | 16:45 |
trozet | janki: let me post it in the comments on the review, so sripriya can see it | 16:45 |
janki | trozet, sure. | 16:46 |
*** alisha has joined #tacker | 16:50 | |
*** vishwanathj has joined #tacker | 16:52 | |
*** janki has quit IRC | 16:59 | |
*** bobh has joined #tacker | 17:02 | |
*** prashantD has joined #tacker | 17:05 | |
*** bobh has quit IRC | 17:08 | |
*** bobh has joined #tacker | 17:09 | |
*** neel has quit IRC | 17:25 | |
*** neel has joined #tacker | 17:30 | |
*** vishnoianil has quit IRC | 17:30 | |
*** sripriya has joined #tacker | 17:37 | |
trozet | hi sripriya | 17:39 |
sripriya | trozet: hello | 17:39 |
trozet | sripriya: 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 IRC | 17:40 | |
sripriya | trozet: looking up | 17:42 |
sripriya | trozet: just caught up | 17:44 |
trozet | sripriya: cool, what do you think? | 17:44 |
sripriya | trozet: are you pointing to returning as {‘resource’: {}. ‘resource’: {},..} | 17:44 |
sripriya | trozet: i mean [‘resource’: {}. ‘resource’: {},..] | 17:44 |
trozet | sripriya: like this https://paste.fedoraproject.org/413445/ | 17:45 |
trozet | [{'resource': 'CP11', 'id': <id>, 'type': 'NeutronPort'}, {'resource': 'CP12', 'id': <id>, 'type': 'NeutronPort'}] | 17:45 |
sripriya | trozet: that means make resource as the subresource for vnfs like: /vnfs/<uuid>/resources? | 17:46 |
sripriya | trozet: btw the response in above link should be : {‘resources’: [{}, {},…} | 17:46 |
sripriya | trozet: corresponding to the wsgi layer | 17:47 |
trozet | sripriya: i think its more like this /vnfs/uuid/detail/<resource> | 17:47 |
trozet | <uuid>* | 17:47 |
trozet | sripriya: similar to how vnfs is /vnfs/<id> | 17:48 |
trozet | s/detail/details/ | 17:48 |
sripriya | trozet: hmm, not sure how <resource> uniquely identifies as in individual ‘detail’ here, | 17:49 |
sripriya | trozet: this is equivalent to detail<—>resource | 17:49 |
sripriya | trozet: tacker should deal with its own resources, not bring a lower layer resource name on to the API layer | 17:51 |
trozet | sripriya: well the <resource> in this case is really VNFD resource name | 17:52 |
trozet | sripriya: ideally you would want to use an ID, but this is OK i think | 17:52 |
trozet | sripriya: i dont think it is a lower layer resource name, because the name is defined in VNFD, which is a tacker/tosca concept | 17:52 |
sripriya | trozet: this is just wrapping heat’s api to the tacker something like http://developer.openstack.org/api-ref-orchestration-v1.html#stack-resources | 17:53 |
sripriya | trozet: what i see here is details sub resource of vnf is always going to imply it should return an infra layer resource information | 17:54 |
trozet | sripriya: well isn't that he point of this patch :) ? | 17:55 |
sripriya | trozet: 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 |
sripriya | trozet: you would rather call the heat client api itself directly to fetch the instance_id resources :-) | 17:55 |
sripriya | trozet: the concern is here to keep it generic | 17:56 |
sripriya | trozet: at the plugin level | 17:56 |
sripriya | trozet: if it is only limiting to fetching resource info , then why have it as ‘details’ ? | 17:57 |
trozet | sripriya: that's a good point, it probably should be s/details/resources, and the attribute should be 'resource_id' or 'resource_name' | 17:58 |
trozet | so /vnfs/<id>/resources/<id> | 17:58 |
sripriya | trozet: yes, well it is our call how we want to do this | 17:59 |
trozet | so you could have resources as the rest extension, then id, name, type as the attributes | 18:00 |
trozet | sripriya: then the only confining detail there is you are expecting all VNFM driver to give you back id,name, and type of resources created | 18:00 |
sripriya | trozet: if we think ‘resources’ is justifiable to be brought up as a sub resource of the vnf , we can modify the url | 18:00 |
sripriya | trozet: that is where i was coming to | 18:00 |
sripriya | trozet: does this apply to all infra drivers? | 18:01 |
trozet | sripriya: but I think that restriction is better than the current approach | 18:01 |
trozet | sripriya: what are the other drivers, just nova? | 18:01 |
sripriya | trozet: beyond openstack may be? | 18:01 |
trozet | sripriya: yeah like aws or something...no idea, but i think, name,id,type are pretty low requirements for hte driver | 18:02 |
sripriya | trozet: i’m fine to modify /s/details/resources unless we have some other good reason to not expose it is a subresource of vnfs | 18:05 |
sripriya | sridhar_ram: ^ | 18:05 |
trozet | sripriya: ok great. Then we could also have get_vnf_resource() and get a single resource id,type,name | 18:06 |
sripriya | trozet: we need to finalize this since this has a client impact | 18:07 |
*** bobh has quit IRC | 18:08 | |
sripriya | trozet: then i assume we introduce a new command on the client side | 18:08 |
trozet | sripriya: yeah | 18:08 |
sripriya | trozet: tacker vnf-resources show ?? | 18:09 |
trozet | sripriya: yeah makes sense, and vnf-resources-list | 18:09 |
trozet | sripriya: do you have a link to the client patch janki is working on? | 18:09 |
sripriya | trozet: that is already merged i believe | 18:10 |
trozet | sripriya: ah | 18:10 |
sripriya | trozet: this has significant change/deviation from the current patch | 18:16 |
*** amotoki has quit IRC | 18:17 | |
trozet | sripriya: yeah, cant we fix the client though as a bug? even after freeze? | 18:17 |
sripriya | trozet: like introducing a new set of commands? :) | 18:17 |
trozet | sripriya: haha :) | 18:18 |
trozet | sripriya: just fixing the current cmd ;) | 18:18 |
trozet | sripriya: if you want I don't mind writing the patch now | 18:18 |
sripriya | trozet: there was no impact at all on current cmds ;) | 18:18 |
sripriya | trozet: i think that would be better | 18:19 |
sripriya | trozet: we can get the review soon and try to merge | 18:19 |
sripriya | trozet; but i would wait for sridhar_ram to waive us a green flag | 18:19 |
trozet | sripriya: oh so there was no new command introduced? it is just part of vnf-show? | 18:19 |
sripriya | trozet: yup | 18:19 |
trozet | sripriya: ah ok | 18:19 |
*** vishnoianil has joined #tacker | 18:23 | |
*** vishwanathj has quit IRC | 18:25 | |
*** vishwanathj has joined #tacker | 18:26 | |
*** tbh has quit IRC | 18:29 | |
sripriya | trozet: to fetch an individual resource are you going to pass the resource name? | 18:29 |
trozet | sripriya: well I guess the first question is, are we able to label a sub resource attribute as primary? | 18:32 |
trozet | sripriya: if yes, then we should probably follow other tacker convention, and make the id the primary key | 18:33 |
sripriya | trozet: we do not store this info in db | 18:33 |
sripriya | trozet: my question is related to what uniquely identifies the resource? | 18:33 |
trozet | sripriya: i think ID, does 'primary_key' in the extension refer to db? | 18:34 |
trozet | sripriya: i thought it referred to the primary key used in the rest resource query | 18:34 |
sripriya | trozet: that is what i understand, was trying to look up how the validation happens | 18:38 |
trozet | sripriya: 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 key | 18:39 |
sripriya | trozet: but resource id is something you only get from resources list with current implemenatation | 18:41 |
sripriya | trozet: fyi for the validation piece https://github.com/openstack/tacker/blob/master/tacker/api/v1/base.py#L260 | 18:41 |
sripriya | trozet: need not be on the id, but that is the typical attribute used as a primary key | 18:41 |
trozet | sripriya: ok then if we can, name would be better, since we know the name from the VNFD | 18:41 |
sripriya | trozet: 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 vnf | 18:42 |
sripriya | trozet: this is not under the control of tacker | 18:43 |
trozet | sripriya: yeah | 18:43 |
sripriya | trozet: 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 uniqueness | 18:43 |
trozet | sripriya: it is more plausible that the ID will be unique than a name | 18:44 |
trozet | more unique* | 18:44 |
sripriya | trozet: we are then enforcing ’id’ on resource which infra driver is expected to handle? | 18:45 |
trozet | sripriya: i think that is an OK expectation. If the infra_driver doesn't support creating sub-resources with IDs, it can simply return not implemented | 18:47 |
sripriya | trozet: so resources will have attributes id, name and type | 18:49 |
trozet | sripriya: right | 18:49 |
sripriya | trozet: resource show in heat is done based on resource name http://developer.openstack.org/api-ref-orchestration-v1.html#stack-resources | 18:50 |
openstackgerrit | Tim Rozet proposed openstack/python-tackerclient: Add client support for VNFFG in NFVO https://review.openstack.org/341389 | 18:51 |
trozet | sripriya: ah | 18:51 |
trozet | sripriya: so then are we OK with using name as primary_key and expecting it to be unique for other drivers? | 18:51 |
sripriya | trozet: i dont know what qualifies as correct implementation with these challenges/ exceptions. i guess we can go with this assumption | 18:52 |
trozet | sripriya: yeah we could always change it later if support for a different VIM comes along and we need to tweak it | 18:54 |
sripriya | trozet: yes | 18:55 |
*** bobh has joined #tacker | 18:55 | |
openstackgerrit | vishwanath jayaraman proposed openstack/tacker: Adds functional tests for common services plugin https://review.openstack.org/358678 | 18:56 |
*** uck has quit IRC | 19:04 | |
*** uck has joined #tacker | 19:05 | |
trozet | sripriya: coming up with a client patch now | 19:07 |
*** uck has quit IRC | 19:09 | |
*** sripriya has quit IRC | 19:21 | |
*** neel has quit IRC | 19:23 | |
*** saju_m has joined #tacker | 19:23 | |
sridhar_ram | trozet: ping | 19:51 |
trozet | sridhar_ram: hello | 19:51 |
sridhar_ram | trozet: just caught up on this discussion.. | 19:53 |
*** sripriya has joined #tacker | 19:54 | |
trozet | sridhar_ram: yeah it was a good one i think | 19:54 |
sridhar_ram | trozet: using vnf-resource-list seems fine.. basically we ditch --details instead use a separate command | 19:54 |
sridhar_ram | trozet: now, on the api it shd be .. /vnf/<uuid>/resources .. correct ? | 19:54 |
trozet | sridhar_ram: right | 19:54 |
trozet | well | 19:55 |
trozet | sridhar_ram: /vnf/<id>/resource/<id> | 19:55 |
trozet | sridhar_ram: sorry forgot we agreed on name as the primary_key | 19:55 |
sridhar_ram | trozet: well, that is a further add-on.. it is optional for now | 19:55 |
trozet | sridhar_ram: so /vnf/<id>/resource/<name> | 19:55 |
trozet | sridhar_ram: yah | 19:56 |
sridhar_ram | trozet: for your vnffg needs /vnd/<id>/resoures should be sufficient | 19:56 |
trozet | sridhar_ram: sure | 19:56 |
sridhar_ram | trozet: okay.. here is a paste .. | 19:56 |
sridhar_ram | trozet: http://paste.openstack.org/show/563124/ | 19:56 |
sridhar_ram | trozet: L9 & L12 | 19:57 |
sridhar_ram | trozet: make sense? | 19:57 |
trozet | sridhar_ram: exactly | 19:57 |
*** s3wong has joined #tacker | 19:58 | |
sridhar_ram | trozet: okay.. let's proceed then.. | 20:00 |
sridhar_ram | trozet: IMO, /vnf/<id>/resource/<id> is a nice to have :) | 20:00 |
sridhar_ram | trozet: i'm telling mostly from timeline point of view.. the deadline is upon us to wrap up tackerclient | 20:01 |
trozet | sridhar_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 time | 20:02 |
sripriya | trozet: ack | 20:04 |
*** uck has joined #tacker | 20:06 | |
sridhar_ram | trozet: sounds good.. | 20:11 |
*** uck has quit IRC | 20:12 | |
openstackgerrit | Merged openstack/tacker: Device refactor Part2: Remove unused scheduler code https://review.openstack.org/352210 | 20:16 |
*** xiayu has quit IRC | 20:23 | |
*** xiayu has joined #tacker | 20:25 | |
sridhar_ram | trozet: btw, this along means we need to revert the changes that went into for --details .. https://review.openstack.org/#/c/354057/ | 20:26 |
openstackgerrit | Merged openstack/tacker: Python 3: dict.itervalues() https://review.openstack.org/346291 | 20:33 |
sridhar_ram | sripriya: bobh: do you folks see any issues with https://review.openstack.org/#/c/330318/ ? | 20:45 |
sridhar_ram | sripriya: 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 deadline | 20:46 |
sripriya | sridhar_ram: i dont see any issues with the client, i think it is good to go | 20:53 |
sridhar_ram | sripriya: thanks a lot for looking into it | 20:53 |
sripriya | sridhar_ram: np | 20:54 |
openstackgerrit | Merged openstack/python-tackerclient: Add "Description" parameter while creating VNF with CLI. https://review.openstack.org/330318 | 21:03 |
*** bobh has quit IRC | 21:33 | |
*** santoshk has joined #tacker | 21:37 | |
*** sripriya has quit IRC | 21:52 | |
*** vishwanathj has quit IRC | 22:02 | |
*** uck has joined #tacker | 22:09 | |
*** uck has quit IRC | 22:14 | |
*** sripriya has joined #tacker | 22:36 | |
*** ksantoshk has joined #tacker | 23:32 | |
*** KanagarajM has joined #tacker | 23:36 | |
*** saju_m has quit IRC | 23:42 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!