Wednesday, 2016-08-10

s3wonggongysh: I can take a look later tonight (pacific time)00:14
gongyshs3wong, do u like watch olympic games?00:16
s3wonggongysh: in US, we got tape delayed :-)00:16
s3wong(at least during prime time)00:16
s3wonggongysh: as a Chinese (HK born), I like that so far China is leading with 8 golds00:17
gongyshs3wong, I like pingpong, badminton, swimming00:18
s3wonggongysh: I like basketball  --- but that is because I am basically an NBA fan :-)00:18
gongyshs3wong,  Because   there are best teams in US.00:19
s3wonggongysh: 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 #tacker00:21
*** prashantD has quit IRC00:25
*** uck has quit IRC00:25
*** sripriya has quit IRC00:27
openstackgerritJianGang Weng proposed openstack/tacker: Remove unused LOG to keep code clean  https://review.openstack.org/34189900:50
sridhar_ramgongysh: are you based of Beijing or Shanghai ?00:52
gongyshsridhar_ram, shanghai00:52
sridhar_ramgongysh: what is exact TZ ? I'm assuming china has diff TZs ?00:52
gongyshit is heard that one of your guys are heading for china.00:52
gongyshsridhar_ram, no, we are using one TZ.00:52
sridhar_ramgongysh: u mean from Brocade ?00:53
gongyshsridhar_ram, I think so.00:54
sridhar_ramgongysh: wow, just looked up one CST for the whole country.. given how huge China and its wide spread00:54
gongyshsridhar_ram, yes.00:55
sridhar_ramgongysh: it is good in a way, from a country productivity point of view..00:55
gongyshsridhar_ram, oh, it is simple anyway.00:56
sridhar_ramgongysh: i'm wondering if moving the mtg to 1400 UTC will help you attend the tacker weekly mtg..00:56
gongyshsridhar_ram, that is ok. I think you have balanced. beijing time is 10:00 PM. not too bad.00:57
sridhar_ramgongysh: 1600 UTC is midnight to you, correct ?00:59
gongyshsridhar_ram,  right. 16:00 + 8 = 24:00.00:59
s3wonggongysh, 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_ramso, i guess moving to 1400 would be better..01:00
sridhar_rams3wong: yeah, yamahata since moved to bay area01:00
gongyshsridhar_ram, compared to 16:00 utc, it is definitely better.01:01
s3wongsridhar_ram: sure, and back then we only had two people in weekly meeting, and I was willing to accommodate :-)01:01
sridhar_rams3wong: :)01:01
sridhar_ramgongysh: sure... perhaps we can consider moving after the newton release deadlines are over..01:02
gongyshsridhar_ram, ok, It seems I still have some happy weeks. :)01:03
* gongysh is zzz...01:03
sridhar_ramgongysh: :)01:06
sridhar_ramgongysh: qq on https://review.openstack.org/#/c/352663/3/doc/source/policies/dev-process.rst01:06
sridhar_ramgongysh: 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 numbered01:07
gongyshsridhar_ram,  actually, I have a patch locally to fix the number order. I can upload it if you are ok.01:20
sridhar_ramgongysh: sure, please go ahea01:20
sridhar_ram*ahead01:20
gongyshsridhar_ram. ok01:20
gongyshdo it in 30 mins when I am at office.01:20
*** gongysh has quit IRC01:21
*** bobh has joined #tacker01:38
*** bobh has quit IRC01:40
*** amotoki has joined #tacker01:40
*** prashantD has joined #tacker01:42
*** gongysh has joined #tacker01:43
*** bobh has joined #tacker01:43
*** s3wong has quit IRC01:47
*** amotoki has quit IRC01:48
openstackgerritgongysh proposed openstack/tacker: Add blueprint only tacker development process  https://review.openstack.org/35266301:50
*** mbound has joined #tacker01:51
*** mbound has quit IRC01:52
*** amotoki has joined #tacker01:58
*** amotoki has quit IRC01:59
*** amotoki has joined #tacker02:00
*** prashantD has quit IRC02:00
*** tbh has joined #tacker02:05
gongyshsridhar_ram, hi02:11
*** uck has joined #tacker02:22
*** KanagarajM has joined #tacker02:25
*** vishnoianil has quit IRC02:25
*** uck has quit IRC02:27
*** bobh has quit IRC02:28
*** bobh has joined #tacker02:31
*** lulei has joined #tacker02:41
*** tbh has quit IRC02:41
*** bobh has quit IRC02:43
*** lulei has quit IRC02:46
*** KanagarajM has quit IRC02:48
*** KanagarajM has joined #tacker02:48
*** KanagarajM has quit IRC02:53
*** KanagarajM has joined #tacker02:53
*** lulei has joined #tacker02:58
*** sripriya has joined #tacker03:28
*** sripriya has quit IRC03:32
openstackgerritvenkatamahesh proposed openstack/tacker: Change the amin_user_name to admin_user_name  https://review.openstack.org/35323403:34
openstackgerritvenkatamahesh proposed openstack/tacker: Change the amin_user_name to admin_user_name  https://review.openstack.org/35323503:35
*** KanagarajM has quit IRC03:39
*** Michael_ has quit IRC03:42
*** links has joined #tacker04:01
*** KanagarajM has joined #tacker04:07
*** dkushwaha has quit IRC04:10
*** vishnoianil has joined #tacker04:21
*** sripriya has joined #tacker04:27
*** gongysh has quit IRC04:30
*** saju_m has joined #tacker04:51
*** saju_m has quit IRC05:02
*** saju_m has joined #tacker05:14
*** neel has joined #tacker05:19
*** sripriya has quit IRC05:21
openstackgerritvishwanath jayaraman proposed openstack/tacker: Adds event plugin for audit support  https://review.openstack.org/32610205:21
openstackgerritvishwanath jayaraman proposed openstack/tacker: Support purge of soft-deleted resources from DB tables  https://review.openstack.org/32965205:21
openstackgerritvishwanath jayaraman proposed openstack/tacker: Adds audit support for VIM, VNFD and VNF  https://review.openstack.org/32516905:21
openstackgerritvishwanath jayaraman proposed openstack/tacker: Logs events for VIM, VNFD and VNF operations  https://review.openstack.org/34915305:21
openstackgerritvishwanath jayaraman proposed openstack/tacker: Enables soft deletion for VIM, VNFD and VNF  https://review.openstack.org/32571805:21
*** sripriya has joined #tacker05:21
vishwanathjKanagarajM 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 IRC05:28
*** janki has joined #tacker05:29
*** neel has quit IRC05:33
vishwanathjKanagarajM 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
vishwanathjlooks 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? tthanks05:35
*** manikanta_tadi has joined #tacker05:37
*** sripriya has quit IRC05:40
openstackgerritvenkatamahesh proposed openstack/tacker: [DOC] Update the manual installation guide to rectify errors  https://review.openstack.org/35325805:41
*** dkushwaha has joined #tacker05:42
*** neel has joined #tacker05:45
*** dkushwaha has quit IRC05:47
*** vishwanathj has quit IRC05:56
*** saju_m has joined #tacker06:18
*** vishwanathj has joined #tacker06:28
*** vishwanathj has quit IRC06:29
*** KanagarajM has quit IRC06:42
*** KanagarajM has joined #tacker06:44
*** Ravikiran_K has joined #tacker06:52
*** KanagarajM has quit IRC07:01
*** KanagarajM has joined #tacker07:01
*** KanagarajM has quit IRC07:06
*** KanagarajM has joined #tacker07:09
*** santoshk has quit IRC07:11
*** dkushwaha has joined #tacker07:17
MuraliHi07:20
Muraliany there any REST API reference for all the tacker for the current developement07:21
Muraliping: Hi all07:23
*** manikanta_tadi has quit IRC07:29
openstackgerritLu lei proposed openstack/tacker: Fix formats for doc's information  https://review.openstack.org/34128107:29
openstackgerritxu-haiwei proposed openstack/python-tackerclient: Remove '--config' option when create/update a vim  https://review.openstack.org/32319207:55
*** prashantD has joined #tacker07:56
openstackgerritLu lei proposed openstack/tacker: Fix formats for doc's information  https://review.openstack.org/34128107:59
*** prashantD has quit IRC08:00
jankiCan someone please share Newton priority etherpad?08:10
*** neel has quit IRC08:17
*** openstackgerrit has quit IRC08:18
*** openstackgerrit has joined #tacker08:19
dkushwahajanki, https://etherpad.openstack.org/p/tacker-newton-release-priority08:22
jankidkushwaha: thanks :)08:23
*** manikanta_tadi has joined #tacker08:25
*** dkushwaha has quit IRC08:28
openstackgerritLu lei proposed openstack/tacker: Fix formats for doc's information  https://review.openstack.org/34128108:31
*** saju_m has quit IRC08:40
*** vishnoianil has quit IRC08:44
*** vishnoianil has joined #tacker08:56
*** saju_m has joined #tacker08:57
openstackgerritManikantha Srinivas Tadi proposed openstack/python-tackerclient: Add service types in tacker vnfd-list.  https://review.openstack.org/34822509:20
*** manikanta_ has joined #tacker09: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 port09: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 #tacker09:44
*** neel has joined #tacker09:51
*** saju_m has quit IRC09:52
openstackgerritgongysh proposed openstack/tacker: Use devstack system public auth url as default VIM auth_url  https://review.openstack.org/35336110:04
*** saju_m has joined #tacker10:05
*** tbh has joined #tacker10:15
*** lulei has quit IRC10:22
*** mbound has quit IRC10:33
*** lulei has joined #tacker10:35
neeljanki, Here it is. #link https://etherpad.openstack.org/p/tacker-newton-release-priority10:39
jankineel, 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 port10:56
priya_anybody faced the similar issue?10:56
*** Ravikiran_K has quit IRC11:06
*** tbh has quit IRC11:10
*** tbh has joined #tacker11:11
*** amotoki has quit IRC11:51
*** amotoki has joined #tacker11:56
openstackgerritgongysh proposed openstack/tacker: Use devstack system public auth url as default VIM auth_url  https://review.openstack.org/35336111:59
*** amotoki has quit IRC12:00
*** links has quit IRC12:01
*** amotoki has joined #tacker12:15
*** achatterjee has joined #tacker12:15
*** _achatterjee_ has quit IRC12:17
*** amotoki has quit IRC12:28
*** neel has quit IRC12:45
*** uck has joined #tacker13:04
*** manikanta_tadi has quit IRC13:05
*** manikanta_ has quit IRC13:05
*** KanagarajM_ has joined #tacker13:08
*** KanagarajM has quit IRC13:08
*** amotoki has joined #tacker13:15
veena_trozet, ping13:20
trozetveena_: hello13:20
veena_I'm testing sfc using tacker SFC_colorado branch and yardstick13:21
veena_in yardstick, it is mentioned, the flows ovs flows created by tacker are wrong and they are changing the classifier flows13:21
veena_https://wiki.opnfv.org/pages/viewpage.action?pageId=682395513: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 port13:23
trozetveena_: yeah there is a bug there I think with setting the SFF IP13:23
veena_trozet, flows for your reference http://paste.openstack.org/show/553563/13:26
trozetveena_: 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 patches13:28
trozetrnoriega: any word on the rebase for the SFC patches?^13:28
*** vishwanathj has joined #tacker13: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 me13:33
*** bobh has joined #tacker13:34
trozetveena_: if you use the apex walkthrough with brahmaputra it will work, with 1 compute13:34
*** bobh has quit IRC13: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 IRC13:39
trozetveena_: 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 manually13:39
veena_trozet, okay thanks13:44
*** bobh has joined #tacker13:52
*** KanagarajM_ has quit IRC13:59
*** bobh has quit IRC14:15
*** lulei has quit IRC14:17
*** lulei has joined #tacker14:17
*** KanagarajM has joined #tacker14:25
*** janki has quit IRC14:31
*** saju_m has quit IRC15:01
*** Qiming_ has joined #tacker15:03
*** Qiming has quit IRC15:04
*** LamT_ has joined #tacker15:05
trozetsridhar_ram: ping?15:14
*** janki has joined #tacker15:38
vishwanathjKanagarajM hi15:43
*** KanagarajM has quit IRC16:03
*** janki has quit IRC16:34
*** janki has joined #tacker16:35
*** Qiming_ has quit IRC16:36
*** Qiming has joined #tacker16:41
*** swat30 has joined #tacker16:53
*** prashantD has joined #tacker17:02
*** sripriya has joined #tacker17:06
jankisripriya: ping17:09
*** saju_m has joined #tacker17:09
sripriyajanki: pong17:09
jankisripriya: addressing your comments on https://review.openstack.org/#/c/340838/17:10
jankiI have created a sub-resource and implemented vnf/uuid/detail api17:11
jankimy question is get_vnf needs to be called inside get_vnf_detail only then the output will be all columns currently available + vnf details17:12
jankiinstead, the earlier approach gives vnf_details by default17:12
jankisecondly, making details optional wont work with vnf-show -F details17:13
jankiit will only show when vnf-show --details command is used17:13
jankisripriya: ^^17:13
sripriyajanki: 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
jankiso 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 server17:20
sripriyajanki: yes, it can be just vnf-show —details.17:21
jankinow to have normal resource fetch, get_vnf needs to be called from get_vnf_details17:21
jankiusing --show-details because it is already avaliable17:21
jankiI have also created a sub resource map17:22
jankiadded the get_vnf_details as an abstract method17:22
jankisripriya: this is what you meant in your comments right?17:23
sripriyajanki: —show-details is for list command i believe17:23
jankiit works with show too. I am using it17:23
sripriyajanki: okay17:24
sripriyajanki: yes i see that17:24
jankithough the option doesnot show out in help17:24
sripriyajanki: yes, to answer your above question.17:24
jankimeaning, tacker vnf-show (enter)17:24
jankihelp wont mention --shoe-details option17:25
*** vishnoianil has quit IRC17:26
jankisripriya: 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
sripriyajanki: it does, i see that option.17:27
jankii couldnot see. will look again tomorrow17:27
sripriyajanki: you will need to check your resource attribute mapping17:28
jankisripriya: you mean need to have vnf-details in resource attr. map same as vnf?17:28
sripriyajanki: 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
jankivnf-details, I have added vnf-details in sub resource attribute map17:29
jankisripriya: I hope I am not eating up your time.17:30
jankisripriya: but nf-details need to be added in resource attr. map or sub resource attr. map?17:30
sripriyajanki: detail and details are two different sub resources, if you have ‘detail’ in your map, you will need the method as get_vnf_detail17:30
jankiI have vnf-details in map17:31
jankinot sure whether to put in resource map or sub resource map17:31
sripriyajanki: why dont you submit a patchset  with workflow -1 and we can review in gerrit. easier that way to debug.17:33
jankisripriya: 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
sripriyajanki: responding in gerrit.17:34
jankisripriya: sure will do that first thing tomorrow morning17:34
jankisripriya: cool. Will log off then. Have a good day ahead17:35
sripriyajanki: good night.17:35
janki bye :)17:35
*** janki has quit IRC17:36
*** s3wong has joined #tacker17:41
*** Qiming has quit IRC17:51
*** ShaikApsar has joined #tacker17:53
*** Qiming has joined #tacker17:55
vishwanathjHi....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 IRC18:00
*** prashantD_ has joined #tacker18:01
*** prashantD has quit IRC18:03
vishwanathjthe 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 absence18:03
*** ShaikApsar has joined #tacker18:04
*** prashantD has joined #tacker18:12
*** prashantD_ has quit IRC18:14
*** Qiming has quit IRC18:14
*** Ravikiran_K has joined #tacker18:18
*** Qiming has joined #tacker18:20
*** Qiming has quit IRC18:23
*** ShaikApsar_ has joined #tacker18:24
*** ShaikApsar has quit IRC18:25
*** Qiming has joined #tacker18:29
*** vishnoianil has joined #tacker18:30
*** Qiming has quit IRC18:37
*** Qiming has joined #tacker18:42
trozetsridhar_ram, s3wong: ping?18:49
trozetsripriya: ping?18:49
sridhar_ramtrozet: pong19:02
trozetsridhar_ram: hey, got a few questions19:03
sridhar_ramtrozet: shoot19:03
trozetsridhar_ram: one thing we didn't account for in the spec, but I see is required due to the vim stuff, is vim_auth19:03
trozetsridhar_ram: I didn't implement that into the current VNFFG stuff19:03
trozetsridhar_ram: but i'm guessing it needs to be there, correct?19:04
sridhar_ramsripriya: the vim expert ^^^19:04
*** sripriya has quit IRC19:04
sridhar_ramtrozet: can u elaborate a bit ?19:04
trozetsridhar_ram: it looks like to invoke the networking-sfc driver, I have to pass s3wong vim_auth credentials19:05
sridhar_ramtrozet: got it, yes..19:05
trozetsridhar_ram: I looked at vnfm plugin.py: vim_auth = self.get_vim(context, device_info)19:06
trozetsridhar_ram: vim_res = self.vim_client.get_vim(context, device['vim_id'],19:06
trozet                                          region_name)19:06
trozetsridhar_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 #tacker19:08
sripriyatrozet: yes19:09
* sridhar_ram wandered back after an interrupt19:10
sripriyatrozet: trying to recall the workflow here19:10
sridhar_ramtrozet: there are two components here .. openstack_driver and vnffg's driver...19:11
sripriyatrozet: vnffg will always pick already created VNFs right?19:11
sridhar_ramimo, openstack_driver shd contain the implementation for vnffg driver for openstack19:11
sridhar_ramspecifically, https://github.com/openstack/tacker/blob/master/tacker/nfvo/drivers/vim/openstack_driver.py19:12
sridhar_rami think s3wong's driver want go into this ^^^19:12
sridhar_ramwhich will implement the VNFFG abstract driver interface19:12
* sridhar_ram quickly looking up s3wong's patchset19:13
trozetsridhar_ram: yes that was my initial thought as well, but it does not appear to be the current way19:14
trozetsridhar_ram: but regardless of the driver, I need to pass vim_auth down to a driver..right?19:14
sridhar_ramtrozet: essentially fold https://review.openstack.org/#/c/347568/3/tacker/nfvo/drivers/vnffg/sfc_drivers/networking_sfc/n_sfc.py into openstack_driver19:15
trozetsridhar_ram: yes that makes sense to me19:15
trozetsridhar_ram: but as i'm writing the plugin, i don't really care where the driver is19:15
sridhar_ramtrozet: yes, tacker service needs to connect to networking-sfc API endpoint19:15
trozetsridhar_ram: i'm just using a noop to test19:15
sridhar_ramtrozet: sure, but thanks for bringing this..19:15
trozetsridhar_ram: ok so then I can do the same thing VNFM is doing with a get_vim function?19:16
sridhar_ramtrozet: still, you need to pass the "vim" info down to the driver...19:16
trozetsridhar_ram: I'm just not familiar with the vim code, so I want to make sure I'm not missing anything19:16
sridhar_ramtrozet: what is currently in scope for ur spec is .. all VNFs in the ffg chain SHOULD BE landed in the same VIM19:17
sridhar_ramtrozet: I'd recommend ffg plugin explicit do this check and fail if above condition is not true19:17
trozetsridhar_ram: ah so I need to check that when i get vim that hte VNFs are also in the same VIM?19:17
trozetsridhar_ram: ok makes sense19:18
trozetsridhar_ram: so another question related to accessing VIM...19:18
sridhar_ramand only that one vim info need to be passed down to the n-sfc driver19:18
trozetsridhar_ram: currently we define a list of match criteria in the policy of a vnffgd19:18
trozetsridhar_ram: I allow for matching on names or id of certain key, like network_name, which could be a neutron network name19:19
trozetsridhar_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 is19:19
trozetsridhar_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
trozetsridhar_ram: actually maybe now it makes a lot more sense, per our conversation, the openstack_driver...19:20
sridhar_ramyes, driver would be the right place to do such "vim" specific things..19:20
sridhar_ramimagine a world where the vim is VMware :)19:20
sridhar_rami know we are bit "uneven" at few places.. but that's where we are heading19:21
trozetsridhar_ram: right, that's why i made the policy key "network_name" instead of "neutron network name" ;)19:21
sridhar_ramcool!19:21
trozetsridhar_ram: ok then I think you answered those 2 questions for me19:21
* sripriya catching up19:22
sridhar_rams3wong: ^^^19:22
trozetsridhar_ram: the other TODO on my plate is validating the VNFFGD19:22
trozetsridhar_ram: I know you guys use the TOSCA translator stuff and invoke a heat driver call to verify it19:22
trozetsridhar_ram: right now I don't do any of that19:22
trozetsridhar_ram:  I'm guessing that is required to get my patch through, right?19:23
sripriyatrozet: why would vnffg need vim info when that vim info is already tried to existing VNFs?19:23
trozetsripriya: I guess I could just use the VNF's vim_auth if all the VNFs have the same vim_auth19:24
trozetsripriya: what about chains that are across VIMs?19:24
*** sripriya has quit IRC19:33
*** sripriya has joined #tacker19:37
vishwanathjtrozet curious, is chaining across VIMs planned to be supported in the first iteration?19:38
trozetvishwanathj: no, just wondering if we should take it into consideration for how it is implemented now, so it will be easier to add later19:39
vishwanathjgot it19:39
sripriyatrozet: yes, that is something to think upon, but it will be implemented by removing the validation of a single vim id.. right?19:40
trozetsripriya: 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 calls19:43
trozetsripriya: is that ok?19:43
sripriyatrozet: yes, and as discussed earlier you need to validate vim ids in all these VNFs are the same19:43
trozetsripriya: yeah makes sense19:44
trozetsripriya: what about the other question about validating vnffgd19:44
trozetsripriya: should I invoke the same heat driver that vnfm uses?19:44
sripriyatrozet: you mean the create_device_template_pre logic?19:45
trozetsripriya: yeah19:47
sripriyatrozet: 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
trozetsripriya: oh I thought the vnfd validation, just validatest he TOSCA format?19:51
trozetvalidates the*19:51
sripriyatrozet: that is all it does and some modifications in the vnfd request body.19:53
sripriyatrozet: you can handle the validation your driver which is basically to call the tosca parser with the yaml and handle the error.19:53
sripriyatrozet: if any19:54
trozetsripriya: so that piece should be done in the openstack_driver ?19:54
sripriyatrozet: yes, do not invoke heat driver for the validation19:54
trozetsripriya: ok got it thanks19:55
sripriyatrozet: np19:55
*** uck has joined #tacker19:57
* s3wong catching up on conversation between trozet and others20:20
trozetsripriya: still around?20:37
*** sripriya has quit IRC20:39
trozetsridhar_ram?20:40
sridhar_ramtrozet: hi20:41
trozetsridhar_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
trozetsridhar_ram: what does that resolve to?20:42
*** sripriya has joined #tacker20:46
trozetsridhar_ram: ok nvm i see they resolve to driver types20:48
trozetsridhar_ram, sripriya: we don't expect the user to pass the driver to use in vnffg, right?20:48
sripriyatrozet: right20:56
trozetsripriya: so the invoke command requires a type given, how do I know which one to give it in the plugin?20:56
sripriyatrozet: the only place we would get the type is from the vim resource itself, we will need to map networking-sfc to openstack vim21:02
trozetsripriya: hmm21:03
sripriyatrozet: since networking-sfc will be the sole driver for openstack vim21:03
trozetsripriya: but isnt hte vim_driver provided by a client as well?21:03
*** uck has quit IRC21:03
trozetsripriya: based on the VIM type21:04
*** uck has joined #tacker21:04
sripriyatrozet: the only time the type is supplied for vim is to register the VIM itself21:05
trozetsripriya: right, ok then I will get rid of my code where I try to register specific vnffg drivers21:06
trozetsripriya: i will assume its the same as the vim opnestack driver21:06
sripriyatrozet: but how will you decide to invoke openstack driver in first place from plugin?21:09
trozetsripriya: that's what im staring at the code now looking for...21:09
trozetsripriya: :)21:09
trozetsripriya: maybe the vim type is included with the VNF info?21:09
trozetsripriya: i see vim_id in there?21:11
trozetsripriya: so i could get_vim, to get hte type I guess21:11
sripriyatrozet: yes, i was thinking about the same, but you will need to decide on these details in plugin itself21:14
trozetsripriya: ok...do you think this has any chance of getting in by code freeze?21:15
trozetsripriya: review is going to be 2k lines, I'm not sure how long that review is going to take...21:15
sripriyatrozet: i think we can try to implement v1 and live with some limitations. late iterate on it to make it better and fine tune21:16
sripriyas/late/later21:16
trozetsripriya: ok, can you go ahead and review what is there now, so i can get some feedback?21:18
sridhar_ramtrozet: qq, u recently had an issue with pip upper-constraints...did that resolve for u?21:18
trozetsridhar_ram: yeah upgrading tox fixed it21:18
sridhar_ramtrozet: Thanks21:18
trozetsripriya, 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 method21:19
sripriyatrozet: i have not yet looked into your code, but i will start to review it soon.21:21
trozetsripriya: ok thanks!21:22
s3wongtrozet: caught up... I indeed added that auth related parameter due to having to authenticate Neutron client21:22
trozets3wong: right21:22
s3wongtrozet: this is needed since I am using Neutron client in backend; even if you only have one VIM, this is still needed21:22
trozets3wong: yep21:23
s3wongtrozet: the infra driver under vm/ has this need since day one of our device template days :-021:23
s3wong"legacy driver"21:23
trozets3wong: I think the point was to move your networking-sfc driver into the openstack_driver21:23
vishwanathjtrozet, what's the command to upgrade tox on ubuntu?21:23
s3wongtrozet: now, I have no idea how you are going to get that from VNFFG plugin :-)21:23
trozetvishwanathj: you should just be able to do sudo pip install tox -U21:24
trozets3wong: I think I got it now, I am going ot look atthe VNFs in the chain to compare their VIM auth info21:24
vishwanathjtrozet thanks21:24
s3wongtrozet: why? does openstack-driver not need to authenticate (or pass token since initialization?)21:24
trozets3wong: no it just makes sense logically I think...because neutron is a component of hte openstack vim, hence should live in openstack_driver21:25
s3wongtrozet: is that information available as you parse TOSCA?21:25
trozets3wong: i think the heat driver should be moved there as well21:25
trozets3wong: no that info is available when I know the VNF instance21:25
trozets3wong: and vnffg create time21:25
trozetat*21:25
s3wongtrozet: I see21:26
s3wongtrozet: yeah, since we are architected to support multiple types of VIMs, we can't even assume there will be a keystone21:27
sridhar_rams3wong: 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#L5421:27
s3wongtrozet: 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 to21:28
s3wongsridhar_ram: so heat driver is already there?21:28
trozets3wong: no heat isn't21:29
sridhar_rams3wong: no, we will merge heat driver into openstack_driver.py in a future refactoring21:29
s3wongsridhar_ram, trozet: OK. no problem21:29
sridhar_rams3wong: for now, all new code shd go to the "correct" place21:29
s3wongsridhar_ram: sure21:29
s3wongsridhar_ram: would being a MixIn help alleviate trozet from passing the auth_attr?21:30
sridhar_rams3wong: 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
s3wongsridhar_ram: I see, being a MixIn alleviates n_sfc driver from having to look for which Neutron server to talk to...21:34
sridhar_rams3wong: exactly..21:34
s3wongsridhar_ram: I will need to look into how to do this... is there any example to look at?21:36
vishwanathjtrozet my issues with upper constraints got fixed after I upgraded tox...thanks a bunch21:36
trozetvishwanathj: np!21:37
*** Ravikiran_K has quit IRC21:38
*** ShaikApsar_ has quit IRC21:40
*** LamT_ has quit IRC22:01
*** uck has quit IRC22:10
openstackgerritsajuptpm proposed openstack/tacker: doc change default vim registration via CLI  https://review.openstack.org/34309722:24
*** bobh has joined #tacker22:26
saju_msridhar_ram: sripriya: could you please review following patches22:31
saju_mhttps://review.openstack.org/35212322:31
saju_mhttps://review.openstack.org/35212622:31
saju_mI am planing to add unittests and functional tests after first round review.22:31
*** sripriya has quit IRC22:32
*** sripriya has joined #tacker22:37
*** bobh has quit IRC22:38
sripriyasaju_m: will do22:38
openstackgerritsajuptpm proposed openstack/tacker: Assign floating IP to the vdu  https://review.openstack.org/35212322:38
saju_msripriya: Thanks22:39
*** saju_m has quit IRC22:45
*** uck has joined #tacker23:03
openstackgerritMerged openstack/tacker: Remove trailing whitespaces  https://review.openstack.org/35277423:10
*** prashantD_ has joined #tacker23:12
*** prashantD has quit IRC23:15
*** dkushwaha has joined #tacker23:50

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