s3wong | gongysh: I can take a look later tonight (pacific time) | 00:14 |
---|---|---|
gongysh | s3wong, do u like watch olympic games? | 00:16 |
s3wong | gongysh: in US, we got tape delayed :-) | 00:16 |
s3wong | (at least during prime time) | 00:16 |
s3wong | gongysh: as a Chinese (HK born), I like that so far China is leading with 8 golds | 00:17 |
gongysh | s3wong, I like pingpong, badminton, swimming | 00:18 |
s3wong | gongysh: I like basketball --- but that is because I am basically an NBA fan :-) | 00:18 |
gongysh | s3wong, Because there are best teams in US. | 00:19 |
s3wong | gongysh: true --- but I am also more interested in watching the NBA stars that I already know, rather than a bunch of unknown athletes :-) | 00:20 |
*** uck has joined #tacker | 00:21 | |
*** prashantD has quit IRC | 00:25 | |
*** uck has quit IRC | 00:25 | |
*** sripriya has quit IRC | 00:27 | |
openstackgerrit | JianGang Weng proposed openstack/tacker: Remove unused LOG to keep code clean https://review.openstack.org/341899 | 00:50 |
sridhar_ram | gongysh: are you based of Beijing or Shanghai ? | 00:52 |
gongysh | sridhar_ram, shanghai | 00:52 |
sridhar_ram | gongysh: what is exact TZ ? I'm assuming china has diff TZs ? | 00:52 |
gongysh | it is heard that one of your guys are heading for china. | 00:52 |
gongysh | sridhar_ram, no, we are using one TZ. | 00:52 |
sridhar_ram | gongysh: u mean from Brocade ? | 00:53 |
gongysh | sridhar_ram, I think so. | 00:54 |
sridhar_ram | gongysh: wow, just looked up one CST for the whole country.. given how huge China and its wide spread | 00:54 |
gongysh | sridhar_ram, yes. | 00:55 |
sridhar_ram | gongysh: it is good in a way, from a country productivity point of view.. | 00:55 |
gongysh | sridhar_ram, oh, it is simple anyway. | 00:56 |
sridhar_ram | gongysh: i'm wondering if moving the mtg to 1400 UTC will help you attend the tacker weekly mtg.. | 00:56 |
gongysh | sridhar_ram, that is ok. I think you have balanced. beijing time is 10:00 PM. not too bad. | 00:57 |
sridhar_ram | gongysh: 1600 UTC is midnight to you, correct ? | 00:59 |
gongysh | sridhar_ram, right. 16:00 + 8 = 24:00. | 00:59 |
s3wong | gongysh, sridhar_ram: when yamahata and I started "serviceVM" back in January 2013, our meeting time (due to yamahata) was 10:00pm pacific time :-) | 01:00 |
sridhar_ram | so, i guess moving to 1400 would be better.. | 01:00 |
sridhar_ram | s3wong: yeah, yamahata since moved to bay area | 01:00 |
gongysh | sridhar_ram, compared to 16:00 utc, it is definitely better. | 01:01 |
s3wong | sridhar_ram: sure, and back then we only had two people in weekly meeting, and I was willing to accommodate :-) | 01:01 |
sridhar_ram | s3wong: :) | 01:01 |
sridhar_ram | gongysh: sure... perhaps we can consider moving after the newton release deadlines are over.. | 01:02 |
gongysh | sridhar_ram, ok, It seems I still have some happy weeks. :) | 01:03 |
* gongysh is zzz... | 01:03 | |
sridhar_ram | gongysh: :) | 01:06 |
sridhar_ram | gongysh: qq on https://review.openstack.org/#/c/352663/3/doc/source/policies/dev-process.rst | 01:06 |
sridhar_ram | gongysh: i need to reference [4] twice in the rst file and i'm not sure how auto-generated notes would work.. i think they are linearly numbered | 01:07 |
gongysh | sridhar_ram, actually, I have a patch locally to fix the number order. I can upload it if you are ok. | 01:20 |
sridhar_ram | gongysh: sure, please go ahea | 01:20 |
sridhar_ram | *ahead | 01:20 |
gongysh | sridhar_ram. ok | 01:20 |
gongysh | do it in 30 mins when I am at office. | 01:20 |
*** gongysh has quit IRC | 01:21 | |
*** bobh has joined #tacker | 01:38 | |
*** bobh has quit IRC | 01:40 | |
*** amotoki has joined #tacker | 01:40 | |
*** prashantD has joined #tacker | 01:42 | |
*** gongysh has joined #tacker | 01:43 | |
*** bobh has joined #tacker | 01:43 | |
*** s3wong has quit IRC | 01:47 | |
*** amotoki has quit IRC | 01:48 | |
openstackgerrit | gongysh proposed openstack/tacker: Add blueprint only tacker development process https://review.openstack.org/352663 | 01:50 |
*** mbound has joined #tacker | 01:51 | |
*** mbound has quit IRC | 01:52 | |
*** amotoki has joined #tacker | 01:58 | |
*** amotoki has quit IRC | 01:59 | |
*** amotoki has joined #tacker | 02:00 | |
*** prashantD has quit IRC | 02:00 | |
*** tbh has joined #tacker | 02:05 | |
gongysh | sridhar_ram, hi | 02:11 |
*** uck has joined #tacker | 02:22 | |
*** KanagarajM has joined #tacker | 02:25 | |
*** vishnoianil has quit IRC | 02:25 | |
*** uck has quit IRC | 02:27 | |
*** bobh has quit IRC | 02:28 | |
*** bobh has joined #tacker | 02:31 | |
*** lulei has joined #tacker | 02:41 | |
*** tbh has quit IRC | 02:41 | |
*** bobh has quit IRC | 02:43 | |
*** lulei has quit IRC | 02:46 | |
*** KanagarajM has quit IRC | 02:48 | |
*** KanagarajM has joined #tacker | 02:48 | |
*** KanagarajM has quit IRC | 02:53 | |
*** KanagarajM has joined #tacker | 02:53 | |
*** lulei has joined #tacker | 02:58 | |
*** sripriya has joined #tacker | 03:28 | |
*** sripriya has quit IRC | 03:32 | |
openstackgerrit | venkatamahesh proposed openstack/tacker: Change the amin_user_name to admin_user_name https://review.openstack.org/353234 | 03:34 |
openstackgerrit | venkatamahesh proposed openstack/tacker: Change the amin_user_name to admin_user_name https://review.openstack.org/353235 | 03:35 |
*** KanagarajM has quit IRC | 03:39 | |
*** Michael_ has quit IRC | 03:42 | |
*** links has joined #tacker | 04:01 | |
*** KanagarajM has joined #tacker | 04:07 | |
*** dkushwaha has quit IRC | 04:10 | |
*** vishnoianil has joined #tacker | 04:21 | |
*** sripriya has joined #tacker | 04:27 | |
*** gongysh has quit IRC | 04:30 | |
*** saju_m has joined #tacker | 04:51 | |
*** saju_m has quit IRC | 05:02 | |
*** saju_m has joined #tacker | 05:14 | |
*** neel has joined #tacker | 05:19 | |
*** sripriya has quit IRC | 05:21 | |
openstackgerrit | vishwanath jayaraman proposed openstack/tacker: Adds event plugin for audit support https://review.openstack.org/326102 | 05:21 |
openstackgerrit | vishwanath jayaraman proposed openstack/tacker: Support purge of soft-deleted resources from DB tables https://review.openstack.org/329652 | 05:21 |
openstackgerrit | vishwanath jayaraman proposed openstack/tacker: Adds audit support for VIM, VNFD and VNF https://review.openstack.org/325169 | 05:21 |
openstackgerrit | vishwanath jayaraman proposed openstack/tacker: Logs events for VIM, VNFD and VNF operations https://review.openstack.org/349153 | 05:21 |
openstackgerrit | vishwanath jayaraman proposed openstack/tacker: Enables soft deletion for VIM, VNFD and VNF https://review.openstack.org/325718 | 05:21 |
*** sripriya has joined #tacker | 05:21 | |
vishwanathj | KanagarajM hi... | 05:24 |
-openstackstatus- NOTICE: zuul is being restarted to reload configuration. Jobs should be re-enqueued but if you're missing anything (and it's not on http://status.openstack.org/zuul/) please issue a recheck in 30min. | 05:26 | |
*** saju_m has quit IRC | 05:28 | |
*** janki has joined #tacker | 05:29 | |
*** neel has quit IRC | 05:33 | |
vishwanathj | KanagarajM I am seeing an issue when trying out (cmd ==> tacker-db-manage purge-deleted vnf) the patchset https://review.openstack.org/#/c/329652/14 ... the error message can be seen at http://paste.openstack.org/show/553319/..... | 05:34 |
vishwanathj | looks like a change was made by gongysh around early june that introduces "cfg.CONF.database" that is causing the issue...are you familiar with this and have a solution? tthanks | 05:35 |
*** manikanta_tadi has joined #tacker | 05:37 | |
*** sripriya has quit IRC | 05:40 | |
openstackgerrit | venkatamahesh proposed openstack/tacker: [DOC] Update the manual installation guide to rectify errors https://review.openstack.org/353258 | 05:41 |
*** dkushwaha has joined #tacker | 05:42 | |
*** neel has joined #tacker | 05:45 | |
*** dkushwaha has quit IRC | 05:47 | |
*** vishwanathj has quit IRC | 05:56 | |
*** saju_m has joined #tacker | 06:18 | |
*** vishwanathj has joined #tacker | 06:28 | |
*** vishwanathj has quit IRC | 06:29 | |
*** KanagarajM has quit IRC | 06:42 | |
*** KanagarajM has joined #tacker | 06:44 | |
*** Ravikiran_K has joined #tacker | 06:52 | |
*** KanagarajM has quit IRC | 07:01 | |
*** KanagarajM has joined #tacker | 07:01 | |
*** KanagarajM has quit IRC | 07:06 | |
*** KanagarajM has joined #tacker | 07:09 | |
*** santoshk has quit IRC | 07:11 | |
*** dkushwaha has joined #tacker | 07:17 | |
Murali | Hi | 07:20 |
Murali | any there any REST API reference for all the tacker for the current developement | 07:21 |
Murali | ping: Hi all | 07:23 |
*** manikanta_tadi has quit IRC | 07:29 | |
openstackgerrit | Lu lei proposed openstack/tacker: Fix formats for doc's information https://review.openstack.org/341281 | 07:29 |
openstackgerrit | xu-haiwei proposed openstack/python-tackerclient: Remove '--config' option when create/update a vim https://review.openstack.org/323192 | 07:55 |
*** prashantD has joined #tacker | 07:56 | |
openstackgerrit | Lu lei proposed openstack/tacker: Fix formats for doc's information https://review.openstack.org/341281 | 07:59 |
*** prashantD has quit IRC | 08:00 | |
janki | Can someone please share Newton priority etherpad? | 08:10 |
*** neel has quit IRC | 08:17 | |
*** openstackgerrit has quit IRC | 08:18 | |
*** openstackgerrit has joined #tacker | 08:19 | |
dkushwaha | janki, https://etherpad.openstack.org/p/tacker-newton-release-priority | 08:22 |
janki | dkushwaha: thanks :) | 08:23 |
*** manikanta_tadi has joined #tacker | 08:25 | |
*** dkushwaha has quit IRC | 08:28 | |
openstackgerrit | Lu lei proposed openstack/tacker: Fix formats for doc's information https://review.openstack.org/341281 | 08:31 |
*** saju_m has quit IRC | 08:40 | |
*** vishnoianil has quit IRC | 08:44 | |
*** vishnoianil has joined #tacker | 08:56 | |
*** saju_m has joined #tacker | 08:57 | |
openstackgerrit | Manikantha Srinivas Tadi proposed openstack/python-tackerclient: Add service types in tacker vnfd-list. https://review.openstack.org/348225 | 09:20 |
*** manikanta_ has joined #tacker | 09:23 | |
priya_ | Hi, I am testing sfc on fuel 9 using yardstick following the steps given in https://wiki.opnfv.org/pages/viewpage.action?pageId=6823955. I am using sfc_colorado branch of tim rozet's tacker repo to install tacker. | 09:36 |
priya_ | After creating the classifier and setting the flows packets are getting dropped at vxlan-gpe port | 09:36 |
priya_ | the expected result is - packets from client to server should pass through SF. Has anybody faced similar issue? any idea how to solve this? | 09:37 |
*** mbound has joined #tacker | 09:44 | |
*** neel has joined #tacker | 09:51 | |
*** saju_m has quit IRC | 09:52 | |
openstackgerrit | gongysh proposed openstack/tacker: Use devstack system public auth url as default VIM auth_url https://review.openstack.org/353361 | 10:04 |
*** saju_m has joined #tacker | 10:05 | |
*** tbh has joined #tacker | 10:15 | |
*** lulei has quit IRC | 10:22 | |
*** mbound has quit IRC | 10:33 | |
*** lulei has joined #tacker | 10:35 | |
neel | janki, Here it is. #link https://etherpad.openstack.org/p/tacker-newton-release-priority | 10:39 |
janki | neel, thanks :) | 10:40 |
priya_ | Hi, I am testing sfc on fuel 9 using yardstick following the steps given in https://wiki.opnfv.org/pages/viewpage.action?pageId=6823955. I am using sfc_colorado branch of tim rozet's tacker repo to install tacker.After creating the classifier and setting the flows packets are getting dropped at vxlan-gpe port | 10:56 |
priya_ | anybody faced the similar issue? | 10:56 |
*** Ravikiran_K has quit IRC | 11:06 | |
*** tbh has quit IRC | 11:10 | |
*** tbh has joined #tacker | 11:11 | |
*** amotoki has quit IRC | 11:51 | |
*** amotoki has joined #tacker | 11:56 | |
openstackgerrit | gongysh proposed openstack/tacker: Use devstack system public auth url as default VIM auth_url https://review.openstack.org/353361 | 11:59 |
*** amotoki has quit IRC | 12:00 | |
*** links has quit IRC | 12:01 | |
*** amotoki has joined #tacker | 12:15 | |
*** achatterjee has joined #tacker | 12:15 | |
*** _achatterjee_ has quit IRC | 12:17 | |
*** amotoki has quit IRC | 12:28 | |
*** neel has quit IRC | 12:45 | |
*** uck has joined #tacker | 13:04 | |
*** manikanta_tadi has quit IRC | 13:05 | |
*** manikanta_ has quit IRC | 13:05 | |
*** KanagarajM_ has joined #tacker | 13:08 | |
*** KanagarajM has quit IRC | 13:08 | |
*** amotoki has joined #tacker | 13:15 | |
veena_ | trozet, ping | 13:20 |
trozet | veena_: hello | 13:20 |
veena_ | I'm testing sfc using tacker SFC_colorado branch and yardstick | 13:21 |
veena_ | in yardstick, it is mentioned, the flows ovs flows created by tacker are wrong and they are changing the classifier flows | 13:21 |
veena_ | https://wiki.opnfv.org/pages/viewpage.action?pageId=6823955 | 13:21 |
veena_ | action: "resubmit(VXGPE_PORT,0)" instead of "output:" | 13:22 |
veena_ | with the tacker created flows or with yardstick changed flows, packets get dropped at vxlangpe port | 13:23 |
trozet | veena_: yeah there is a bug there I think with setting the SFF IP | 13:23 |
veena_ | trozet, flows for your reference http://paste.openstack.org/show/553563/ | 13:26 |
trozet | veena_: yeah it's something we need to test and fix, but just today boron got fixed, so we need to get a new build with Brady's patches | 13:28 |
trozet | rnoriega: any word on the rebase for the SFC patches?^ | 13:28 |
*** vishwanathj has joined #tacker | 13:30 | |
veena_ | trozet, Okay. Does the bug effects both the flows ? (one with action as output:VXGPE port another resubmit to VXGPE,0) | 13:32 |
veena_ | trozet, because even https://github.com/trozet/sfc-random/blob/master/tacker_sfc_walkthrough.txt also didn't work for me | 13:33 |
*** bobh has joined #tacker | 13:34 | |
trozet | veena_: if you use the apex walkthrough with brahmaputra it will work, with 1 compute | 13:34 |
*** bobh has quit IRC | 13:35 | |
veena_ | trozet, okay. I'm using fuel. So if I change the source_port to 2000 in the match field while creating the classifier, is that the only change to get it working? | 13:38 |
*** uck has quit IRC | 13:39 | |
trozet | veena_: no i think that is a separate thing. You have to include the source port in your match criteria, but that one flow that you talked about needs to be modified. I believe brady was modifying it manually | 13:39 |
veena_ | trozet, okay thanks | 13:44 |
*** bobh has joined #tacker | 13:52 | |
*** KanagarajM_ has quit IRC | 13:59 | |
*** bobh has quit IRC | 14:15 | |
*** lulei has quit IRC | 14:17 | |
*** lulei has joined #tacker | 14:17 | |
*** KanagarajM has joined #tacker | 14:25 | |
*** janki has quit IRC | 14:31 | |
*** saju_m has quit IRC | 15:01 | |
*** Qiming_ has joined #tacker | 15:03 | |
*** Qiming has quit IRC | 15:04 | |
*** LamT_ has joined #tacker | 15:05 | |
trozet | sridhar_ram: ping? | 15:14 |
*** janki has joined #tacker | 15:38 | |
vishwanathj | KanagarajM hi | 15:43 |
*** KanagarajM has quit IRC | 16:03 | |
*** janki has quit IRC | 16:34 | |
*** janki has joined #tacker | 16:35 | |
*** Qiming_ has quit IRC | 16:36 | |
*** Qiming has joined #tacker | 16:41 | |
*** swat30 has joined #tacker | 16:53 | |
*** prashantD has joined #tacker | 17:02 | |
*** sripriya has joined #tacker | 17:06 | |
janki | sripriya: ping | 17:09 |
*** saju_m has joined #tacker | 17:09 | |
sripriya | janki: pong | 17:09 |
janki | sripriya: addressing your comments on https://review.openstack.org/#/c/340838/ | 17:10 |
janki | I have created a sub-resource and implemented vnf/uuid/detail api | 17:11 |
janki | my question is get_vnf needs to be called inside get_vnf_detail only then the output will be all columns currently available + vnf details | 17:12 |
janki | instead, the earlier approach gives vnf_details by default | 17:12 |
janki | secondly, making details optional wont work with vnf-show -F details | 17:13 |
janki | it will only show when vnf-show --details command is used | 17:13 |
janki | sripriya: ^^ | 17:13 |
sripriya | janki: get_vnf does normal resource fetch and get_vnf_detail does normal resource fetch+additional queries, it is better to keep them separate. if get_vnf_details also just retrieved information from db and dumped it, it was fine to merge both of them. the additional thing it does is to fetch heat stack details which is already readily available for the end user and is unnecessary to add this to normal get_vnf. | 17:18 |
janki | so the call to het_vnf_Details would be vnf-show --show-details will call vnf/uuid/details api, then to get_vnf_details fucn on server | 17:20 |
sripriya | janki: yes, it can be just vnf-show —details. | 17:21 |
janki | now to have normal resource fetch, get_vnf needs to be called from get_vnf_details | 17:21 |
janki | using --show-details because it is already avaliable | 17:21 |
janki | I have also created a sub resource map | 17:22 |
janki | added the get_vnf_details as an abstract method | 17:22 |
janki | sripriya: this is what you meant in your comments right? | 17:23 |
sripriya | janki: —show-details is for list command i believe | 17:23 |
janki | it works with show too. I am using it | 17:23 |
sripriya | janki: okay | 17:24 |
sripriya | janki: yes i see that | 17:24 |
janki | though the option doesnot show out in help | 17:24 |
sripriya | janki: yes, to answer your above question. | 17:24 |
janki | meaning, tacker vnf-show (enter) | 17:24 |
janki | help wont mention --shoe-details option | 17:25 |
*** vishnoianil has quit IRC | 17:26 | |
janki | sripriya: 1 very basic query - I have added the get_vnf_details method in extentions as an abstract and implemented its logic in plugin.py file. yet am getting "resource not found error". Am I missing something here? | 17:27 |
sripriya | janki: it does, i see that option. | 17:27 |
janki | i couldnot see. will look again tomorrow | 17:27 |
sripriya | janki: you will need to check your resource attribute mapping | 17:28 |
janki | sripriya: you mean need to have vnf-details in resource attr. map same as vnf? | 17:28 |
sripriya | janki: it means the server was not able to map a method to the resource url. also checking for plural in your resource and any nit issues. | 17:29 |
janki | vnf-details, I have added vnf-details in sub resource attribute map | 17:29 |
janki | sripriya: I hope I am not eating up your time. | 17:30 |
janki | sripriya: but nf-details need to be added in resource attr. map or sub resource attr. map? | 17:30 |
sripriya | janki: detail and details are two different sub resources, if you have ‘detail’ in your map, you will need the method as get_vnf_detail | 17:30 |
janki | I have vnf-details in map | 17:31 |
janki | not sure whether to put in resource map or sub resource map | 17:31 |
sripriya | janki: why dont you submit a patchset with workflow -1 and we can review in gerrit. easier that way to debug. | 17:33 |
janki | sripriya: secondly, you suggested using _fields method. For that either the method needs to be static or its class needs to be instantiated. What would be appropriate? | 17:34 |
sripriya | janki: responding in gerrit. | 17:34 |
janki | sripriya: sure will do that first thing tomorrow morning | 17:34 |
janki | sripriya: cool. Will log off then. Have a good day ahead | 17:35 |
sripriya | janki: good night. | 17:35 |
janki | bye :) | 17:35 |
*** janki has quit IRC | 17:36 | |
*** s3wong has joined #tacker | 17:41 | |
*** Qiming has quit IRC | 17:51 | |
*** ShaikApsar has joined #tacker | 17:53 | |
*** Qiming has joined #tacker | 17:55 | |
vishwanathj | Hi....anyone familiar with the changes that went into api.py as part of patchset https://review.openstack.org/#/c/325089/4/tacker/db/api.py .... | 17:59 |
*** ShaikApsar has quit IRC | 18:00 | |
*** prashantD_ has joined #tacker | 18:01 | |
*** prashantD has quit IRC | 18:03 | |
vishwanathj | the above patchset got merged sometime in June, My patchset https://review.openstack.org/#/c/329652/14/tacker/db/api.py uses the _create_facade_lazily() and is failing....would help if I could discuss with someone familiar with this code in gongysh absence | 18:03 |
*** ShaikApsar has joined #tacker | 18:04 | |
*** prashantD has joined #tacker | 18:12 | |
*** prashantD_ has quit IRC | 18:14 | |
*** Qiming has quit IRC | 18:14 | |
*** Ravikiran_K has joined #tacker | 18:18 | |
*** Qiming has joined #tacker | 18:20 | |
*** Qiming has quit IRC | 18:23 | |
*** ShaikApsar_ has joined #tacker | 18:24 | |
*** ShaikApsar has quit IRC | 18:25 | |
*** Qiming has joined #tacker | 18:29 | |
*** vishnoianil has joined #tacker | 18:30 | |
*** Qiming has quit IRC | 18:37 | |
*** Qiming has joined #tacker | 18:42 | |
trozet | sridhar_ram, s3wong: ping? | 18:49 |
trozet | sripriya: ping? | 18:49 |
sridhar_ram | trozet: pong | 19:02 |
trozet | sridhar_ram: hey, got a few questions | 19:03 |
sridhar_ram | trozet: shoot | 19:03 |
trozet | sridhar_ram: one thing we didn't account for in the spec, but I see is required due to the vim stuff, is vim_auth | 19:03 |
trozet | sridhar_ram: I didn't implement that into the current VNFFG stuff | 19:03 |
trozet | sridhar_ram: but i'm guessing it needs to be there, correct? | 19:04 |
sridhar_ram | sripriya: the vim expert ^^^ | 19:04 |
*** sripriya has quit IRC | 19:04 | |
sridhar_ram | trozet: can u elaborate a bit ? | 19:04 |
trozet | sridhar_ram: it looks like to invoke the networking-sfc driver, I have to pass s3wong vim_auth credentials | 19:05 |
sridhar_ram | trozet: got it, yes.. | 19:05 |
trozet | sridhar_ram: I looked at vnfm plugin.py: vim_auth = self.get_vim(context, device_info) | 19:06 |
trozet | sridhar_ram: vim_res = self.vim_client.get_vim(context, device['vim_id'], | 19:06 |
trozet | region_name) | 19:06 |
trozet | sridhar_ram: so I can use something similar to get_vim that vnfm is using right? There is nothing special passed to the API for vim_auth? | 19:07 |
*** sripriya has joined #tacker | 19:08 | |
sripriya | trozet: yes | 19:09 |
* sridhar_ram wandered back after an interrupt | 19:10 | |
sripriya | trozet: trying to recall the workflow here | 19:10 |
sridhar_ram | trozet: there are two components here .. openstack_driver and vnffg's driver... | 19:11 |
sripriya | trozet: vnffg will always pick already created VNFs right? | 19:11 |
sridhar_ram | imo, openstack_driver shd contain the implementation for vnffg driver for openstack | 19:11 |
sridhar_ram | specifically, https://github.com/openstack/tacker/blob/master/tacker/nfvo/drivers/vim/openstack_driver.py | 19:12 |
sridhar_ram | i think s3wong's driver want go into this ^^^ | 19:12 |
sridhar_ram | which will implement the VNFFG abstract driver interface | 19:12 |
* sridhar_ram quickly looking up s3wong's patchset | 19:13 | |
trozet | sridhar_ram: yes that was my initial thought as well, but it does not appear to be the current way | 19:14 |
trozet | sridhar_ram: but regardless of the driver, I need to pass vim_auth down to a driver..right? | 19:14 |
sridhar_ram | trozet: essentially fold https://review.openstack.org/#/c/347568/3/tacker/nfvo/drivers/vnffg/sfc_drivers/networking_sfc/n_sfc.py into openstack_driver | 19:15 |
trozet | sridhar_ram: yes that makes sense to me | 19:15 |
trozet | sridhar_ram: but as i'm writing the plugin, i don't really care where the driver is | 19:15 |
sridhar_ram | trozet: yes, tacker service needs to connect to networking-sfc API endpoint | 19:15 |
trozet | sridhar_ram: i'm just using a noop to test | 19:15 |
sridhar_ram | trozet: sure, but thanks for bringing this.. | 19:15 |
trozet | sridhar_ram: ok so then I can do the same thing VNFM is doing with a get_vim function? | 19:16 |
sridhar_ram | trozet: still, you need to pass the "vim" info down to the driver... | 19:16 |
trozet | sridhar_ram: I'm just not familiar with the vim code, so I want to make sure I'm not missing anything | 19:16 |
sridhar_ram | trozet: what is currently in scope for ur spec is .. all VNFs in the ffg chain SHOULD BE landed in the same VIM | 19:17 |
sridhar_ram | trozet: I'd recommend ffg plugin explicit do this check and fail if above condition is not true | 19:17 |
trozet | sridhar_ram: ah so I need to check that when i get vim that hte VNFs are also in the same VIM? | 19:17 |
trozet | sridhar_ram: ok makes sense | 19:18 |
trozet | sridhar_ram: so another question related to accessing VIM... | 19:18 |
sridhar_ram | and only that one vim info need to be passed down to the n-sfc driver | 19:18 |
trozet | sridhar_ram: currently we define a list of match criteria in the policy of a vnffgd | 19:18 |
trozet | sridhar_ram: I allow for matching on names or id of certain key, like network_name, which could be a neutron network name | 19:19 |
trozet | sridhar_ram: my problem is, when I go to parse that into an ID, I need to query neutron to find that id...i'm not sure where the correct place to do that is | 19:19 |
trozet | sridhar_ram: obviously its wrong to do it in the plugin...but is it right to do it in the VNFFG driver (like networking-sfc?) | 19:19 |
trozet | sridhar_ram: actually maybe now it makes a lot more sense, per our conversation, the openstack_driver... | 19:20 |
sridhar_ram | yes, driver would be the right place to do such "vim" specific things.. | 19:20 |
sridhar_ram | imagine a world where the vim is VMware :) | 19:20 |
sridhar_ram | i know we are bit "uneven" at few places.. but that's where we are heading | 19:21 |
trozet | sridhar_ram: right, that's why i made the policy key "network_name" instead of "neutron network name" ;) | 19:21 |
sridhar_ram | cool! | 19:21 |
trozet | sridhar_ram: ok then I think you answered those 2 questions for me | 19:21 |
* sripriya catching up | 19:22 | |
sridhar_ram | s3wong: ^^^ | 19:22 |
trozet | sridhar_ram: the other TODO on my plate is validating the VNFFGD | 19:22 |
trozet | sridhar_ram: I know you guys use the TOSCA translator stuff and invoke a heat driver call to verify it | 19:22 |
trozet | sridhar_ram: right now I don't do any of that | 19:22 |
trozet | sridhar_ram: I'm guessing that is required to get my patch through, right? | 19:23 |
sripriya | trozet: why would vnffg need vim info when that vim info is already tried to existing VNFs? | 19:23 |
trozet | sripriya: I guess I could just use the VNF's vim_auth if all the VNFs have the same vim_auth | 19:24 |
trozet | sripriya: what about chains that are across VIMs? | 19:24 |
*** sripriya has quit IRC | 19:33 | |
*** sripriya has joined #tacker | 19:37 | |
vishwanathj | trozet curious, is chaining across VIMs planned to be supported in the first iteration? | 19:38 |
trozet | vishwanathj: no, just wondering if we should take it into consideration for how it is implemented now, so it will be easier to add later | 19:39 |
vishwanathj | got it | 19:39 |
sripriya | trozet: yes, that is something to think upon, but it will be implemented by removing the validation of a single vim id.. right? | 19:40 |
trozet | sripriya: I'm quite sure how it will all work, but for now why don't I just go the route you suggested, check the VNFs vim_auth and use that for the VNFFG driver calls | 19:43 |
trozet | sripriya: is that ok? | 19:43 |
sripriya | trozet: yes, and as discussed earlier you need to validate vim ids in all these VNFs are the same | 19:43 |
trozet | sripriya: yeah makes sense | 19:44 |
trozet | sripriya: what about the other question about validating vnffgd | 19:44 |
trozet | sripriya: should I invoke the same heat driver that vnfm uses? | 19:44 |
sripriya | trozet: you mean the create_device_template_pre logic? | 19:45 |
trozet | sripriya: yeah | 19:47 |
sripriya | trozet: i actually have a patch that extracts the validation logic into a separate module so that it is reusable by both vnfd and vnffgd, ( i need to set some time aside to move the patch forward :( ), for now i would say let us not tie two driver calls, heat driver is not the right place to validate the template,, you would need to handle it in the openstack_driver itself to query neutron for policies etc. | 19:49 |
trozet | sripriya: oh I thought the vnfd validation, just validatest he TOSCA format? | 19:51 |
trozet | validates the* | 19:51 |
sripriya | trozet: that is all it does and some modifications in the vnfd request body. | 19:53 |
sripriya | trozet: you can handle the validation your driver which is basically to call the tosca parser with the yaml and handle the error. | 19:53 |
sripriya | trozet: if any | 19:54 |
trozet | sripriya: so that piece should be done in the openstack_driver ? | 19:54 |
sripriya | trozet: yes, do not invoke heat driver for the validation | 19:54 |
trozet | sripriya: ok got it thanks | 19:55 |
sripriya | trozet: np | 19:55 |
*** uck has joined #tacker | 19:57 | |
* s3wong catching up on conversation between trozet and others | 20:20 | |
trozet | sripriya: still around? | 20:37 |
*** sripriya has quit IRC | 20:39 | |
trozet | sridhar_ram? | 20:40 |
sridhar_ram | trozet: hi | 20:41 |
trozet | sridhar_ram: hey, in the plugin, it looks like the driver is invoked by specifying a "type_". Looking in driver_manager type_ = ext.obj.get_type() | 20:41 |
trozet | sridhar_ram: what does that resolve to? | 20:42 |
*** sripriya has joined #tacker | 20:46 | |
trozet | sridhar_ram: ok nvm i see they resolve to driver types | 20:48 |
trozet | sridhar_ram, sripriya: we don't expect the user to pass the driver to use in vnffg, right? | 20:48 |
sripriya | trozet: right | 20:56 |
trozet | sripriya: so the invoke command requires a type given, how do I know which one to give it in the plugin? | 20:56 |
sripriya | trozet: the only place we would get the type is from the vim resource itself, we will need to map networking-sfc to openstack vim | 21:02 |
trozet | sripriya: hmm | 21:03 |
sripriya | trozet: since networking-sfc will be the sole driver for openstack vim | 21:03 |
trozet | sripriya: but isnt hte vim_driver provided by a client as well? | 21:03 |
*** uck has quit IRC | 21:03 | |
trozet | sripriya: based on the VIM type | 21:04 |
*** uck has joined #tacker | 21:04 | |
sripriya | trozet: the only time the type is supplied for vim is to register the VIM itself | 21:05 |
trozet | sripriya: right, ok then I will get rid of my code where I try to register specific vnffg drivers | 21:06 |
trozet | sripriya: i will assume its the same as the vim opnestack driver | 21:06 |
sripriya | trozet: but how will you decide to invoke openstack driver in first place from plugin? | 21:09 |
trozet | sripriya: that's what im staring at the code now looking for... | 21:09 |
trozet | sripriya: :) | 21:09 |
trozet | sripriya: maybe the vim type is included with the VNF info? | 21:09 |
trozet | sripriya: i see vim_id in there? | 21:11 |
trozet | sripriya: so i could get_vim, to get hte type I guess | 21:11 |
sripriya | trozet: yes, i was thinking about the same, but you will need to decide on these details in plugin itself | 21:14 |
trozet | sripriya: ok...do you think this has any chance of getting in by code freeze? | 21:15 |
trozet | sripriya: review is going to be 2k lines, I'm not sure how long that review is going to take... | 21:15 |
sripriya | trozet: i think we can try to implement v1 and live with some limitations. late iterate on it to make it better and fine tune | 21:16 |
sripriya | s/late/later | 21:16 |
trozet | sripriya: ok, can you go ahead and review what is there now, so i can get some feedback? | 21:18 |
sridhar_ram | trozet: qq, u recently had an issue with pip upper-constraints...did that resolve for u? | 21:18 |
trozet | sridhar_ram: yeah upgrading tox fixed it | 21:18 |
sridhar_ram | trozet: Thanks | 21:18 |
trozet | sripriya, sridhar_ram: I'm wondering if the double foreign key constraint between nfp<-->chain table is going to be a -1 in code review. Wondering if i should just remove the double constraint and parse the chain_id in make_dict method | 21:19 |
sripriya | trozet: i have not yet looked into your code, but i will start to review it soon. | 21:21 |
trozet | sripriya: ok thanks! | 21:22 |
s3wong | trozet: caught up... I indeed added that auth related parameter due to having to authenticate Neutron client | 21:22 |
trozet | s3wong: right | 21:22 |
s3wong | trozet: this is needed since I am using Neutron client in backend; even if you only have one VIM, this is still needed | 21:22 |
trozet | s3wong: yep | 21:23 |
s3wong | trozet: the infra driver under vm/ has this need since day one of our device template days :-0 | 21:23 |
s3wong | "legacy driver" | 21:23 |
trozet | s3wong: I think the point was to move your networking-sfc driver into the openstack_driver | 21:23 |
vishwanathj | trozet, what's the command to upgrade tox on ubuntu? | 21:23 |
s3wong | trozet: now, I have no idea how you are going to get that from VNFFG plugin :-) | 21:23 |
trozet | vishwanathj: you should just be able to do sudo pip install tox -U | 21:24 |
trozet | s3wong: I think I got it now, I am going ot look atthe VNFs in the chain to compare their VIM auth info | 21:24 |
vishwanathj | trozet thanks | 21:24 |
s3wong | trozet: why? does openstack-driver not need to authenticate (or pass token since initialization?) | 21:24 |
trozet | s3wong: no it just makes sense logically I think...because neutron is a component of hte openstack vim, hence should live in openstack_driver | 21:25 |
s3wong | trozet: is that information available as you parse TOSCA? | 21:25 |
trozet | s3wong: i think the heat driver should be moved there as well | 21:25 |
trozet | s3wong: no that info is available when I know the VNF instance | 21:25 |
trozet | s3wong: and vnffg create time | 21:25 |
trozet | at* | 21:25 |
s3wong | trozet: I see | 21:26 |
s3wong | trozet: yeah, since we are architected to support multiple types of VIMs, we can't even assume there will be a keystone | 21:27 |
sridhar_ram | s3wong: the short summary is, https://review.openstack.org/#/c/347568/3/tacker/nfvo/drivers/vnffg/sfc_drivers/networking_sfc/n_sfc.py needs to fold in as a MixIn into https://github.com/openstack/tacker/blob/master/tacker/nfvo/drivers/vim/openstack_driver.py#L54 | 21:27 |
s3wong | trozet: is code reorganized? I thought individual drivers are still under their respective vm/ or nfvo/ directories --- the name of driver ('heat' or 'networking-sfc') basically points to which type of VIM this driver belongs to | 21:28 |
s3wong | sridhar_ram: so heat driver is already there? | 21:28 |
trozet | s3wong: no heat isn't | 21:29 |
sridhar_ram | s3wong: no, we will merge heat driver into openstack_driver.py in a future refactoring | 21:29 |
s3wong | sridhar_ram, trozet: OK. no problem | 21:29 |
sridhar_ram | s3wong: for now, all new code shd go to the "correct" place | 21:29 |
s3wong | sridhar_ram: sure | 21:29 |
s3wong | sridhar_ram: would being a MixIn help alleviate trozet from passing the auth_attr? | 21:30 |
sridhar_ram | s3wong: no that is an independent thing.. vim-info need to be passed down the "driver" in this case openstack_driver as it needs keystone url, creds, etc to reach the target services (like keystone, neutron, heat) | 21:32 |
s3wong | sridhar_ram: I see, being a MixIn alleviates n_sfc driver from having to look for which Neutron server to talk to... | 21:34 |
sridhar_ram | s3wong: exactly.. | 21:34 |
s3wong | sridhar_ram: I will need to look into how to do this... is there any example to look at? | 21:36 |
vishwanathj | trozet my issues with upper constraints got fixed after I upgraded tox...thanks a bunch | 21:36 |
trozet | vishwanathj: np! | 21:37 |
*** Ravikiran_K has quit IRC | 21:38 | |
*** ShaikApsar_ has quit IRC | 21:40 | |
*** LamT_ has quit IRC | 22:01 | |
*** uck has quit IRC | 22:10 | |
openstackgerrit | sajuptpm proposed openstack/tacker: doc change default vim registration via CLI https://review.openstack.org/343097 | 22:24 |
*** bobh has joined #tacker | 22:26 | |
saju_m | sridhar_ram: sripriya: could you please review following patches | 22:31 |
saju_m | https://review.openstack.org/352123 | 22:31 |
saju_m | https://review.openstack.org/352126 | 22:31 |
saju_m | I am planing to add unittests and functional tests after first round review. | 22:31 |
*** sripriya has quit IRC | 22:32 | |
*** sripriya has joined #tacker | 22:37 | |
*** bobh has quit IRC | 22:38 | |
sripriya | saju_m: will do | 22:38 |
openstackgerrit | sajuptpm proposed openstack/tacker: Assign floating IP to the vdu https://review.openstack.org/352123 | 22:38 |
saju_m | sripriya: Thanks | 22:39 |
*** saju_m has quit IRC | 22:45 | |
*** uck has joined #tacker | 23:03 | |
openstackgerrit | Merged openstack/tacker: Remove trailing whitespaces https://review.openstack.org/352774 | 23:10 |
*** prashantD_ has joined #tacker | 23:12 | |
*** prashantD has quit IRC | 23:15 | |
*** dkushwaha has joined #tacker | 23:50 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!