14:00:52 #startmeeting neutron lbaas 14:00:53 Meeting started Thu Dec 19 14:00:52 2013 UTC and is due to finish in 60 minutes. The chair is enikanorov. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:57 The meeting name has been set to 'neutron_lbaas' 14:01:04 hi folks 14:01:15 Hi enikanorov 14:01:22 hi Vijay 14:02:21 #topic announcements 14:03:36 not too much to announce, the tempest scenario test for lbaas that we've created helped us to identify a few issues that came with unified agent patch 14:03:50 yeah 14:03:58 nice 14:04:04 so it would be could if anyone could share a result of running this scenario in their environment 14:05:08 we have not yet tried out, but we have now a setup ready with devstack + appliance 14:05:18 things are not moving much last days because whole team is focused on gate issues 14:05:20 so we should be able to run in a couple of days 14:05:21 Vijay: cool 14:05:45 hi 14:05:48 great. I'm seeing more and more third-party testing systems reporting back test results 14:05:56 hi 14:06:15 I have a question if you dont mind 14:06:16 i think i have seen some report with 'radware' in it 14:06:25 bana_: what is it? 14:07:17 after unified agent when ever agent makes an callback to a plugin which plugin driver will receive it ? 14:07:55 it will be recieved by the LBaaS plugin 14:08:02 not plugin driver 14:08:18 plugin driver sets callbacks on main plugin 14:08:25 enikanorov: We have no reports back yet 14:08:43 The healthmonitor's tempest test is expecting the pool.status to be ACTIVE/INACTIVE according to the status of the server. There is no driver api today. 14:09:12 How is HA proxy doing it? 14:09:22 oh ... thanks thought plugin_driver receives it 14:09:39 Vijay: haproxy does it by colelcting the stats 14:09:54 bana_: np 14:09:57 so how does the stats work? is it collected periodically by tye plugin? 14:09:59 during the stats colelction it identifies dead node and updates it's status 14:10:18 Vijay: it is collected by the agent, in case of haproxy 14:10:34 what does the agent do with the stats? 14:10:52 it sends them to the server 14:10:58 and server handles 14:11:38 so at first agent fetches stats from every pool 14:12:36 sends them to which server? 14:12:48 to the plugin in particular 14:12:57 lbaas plugin 14:13:41 plugin has update_pool_stats callback 14:13:55 ok 14:13:59 this not relevant to any northbound call that the lbaas plugin received right? 14:14:13 it is periodic update to databse? 14:14:22 obondarev: regarding bana_'s question. isn't it LoadbalancerCallbacks that receive calls from the agent, and those callbacks are plugin-driver specific? 14:14:39 Vijay: as a consequence, yes 14:14:54 db gets updated periodically 14:15:23 This is quiet tricky for agentless models. imagine the driver is going to talk to all the devices and getting the stats + status and sending to plugin 14:15:49 Yes was checking the code and I dont see how the plugin is receiving the callbacks 14:15:50 enikanorov: agent_based plugin driver sets LoadbalancerCallbacks on the lbaas plugin 14:15:50 more ever, the driver will not have any trigger-point/thread to do this right? 14:15:50 obondarev: bana_: in other words I'm saying that it's plugin driver that recieves it, rather then plugin itself 14:16:30 Vijay: it could (and probably should) have a separate thread 14:16:57 let me think about it. 14:16:58 enikanorov: bana_: look at AgentBasedPluginDriver code, method _set_callbacks_on_plugin 14:17:04 but if I have multiple plugin drivers and I want to update a status of a particular plugin driver how can I do it 14:17:08 when is the "stats" function called in the driver? 14:17:26 Vijay: see, this is a whole point to employ agents in order to communicate with devices. agent is not required, but then you are to solve this on your own 14:17:39 seems have two parallel threads here 14:17:50 maybe let process one by one 14:17:50 Vijay: during periodic task 14:18:15 ok, lets continue with callback at open discussion section 14:18:24 and discuss stats collection 14:18:25 but since we are using same topic we cant say which one will receives it 14:18:41 ok 14:18:43 bana_: lets discuss at the end of the meeting 14:18:45 ok 14:18:50 Vijay: please go ahead 14:18:53 ok 14:19:13 so this periodic task is called by who? 14:19:34 and what is the purpose? 14:19:57 bana_: meanwhile please look at AgentBasedPluginDriver code, method _set_callbacks_on_plugin 14:20:34 Vijay: currently periodic task is started by the agent 14:20:56 it collects stats every 6 seconds and sends to plugin by rpc 14:20:58 the purpose is to collect the stats from the device and send it back to the db 14:21:20 @obondarev okay 14:21:46 let me see if i understand this. agent is calling the plugin driver.stats() method periodically 14:22:13 and stats() method will call back agent to get the task done 14:22:25 no 14:22:29 not exactly 14:22:32 i believe it is simpler 14:22:36 yeah 14:22:50 agent just collects the stats and send them back to the plugin 14:22:55 actially I understand Vijay concern with the stats 14:22:56 each n seconds 14:23:07 not all plugin drivers will be using agent 14:23:26 yes, that was discussed 14:23:29 still i didnt not understand the purpose of the "stats" function then 14:23:35 so it's not good to establish periodic task in every plugin driver 14:23:50 but anyway it's better to separate rest call processing from actual communication with the device 14:24:02 and it makes sense to run that task on the plugin side 14:24:24 enikanorov: agree 14:24:46 rest call will return stats from db 14:24:49 in fact it doesn't matter where to run stats collection 14:25:16 the only requirement should be that collecting stats should not be initiated by the rest call 14:25:28 so it gotta be automatic 14:25:36 correct. i think the plugin should call the stats function periodically and it should reach the plugin driver which can return the stats and that can be stored by the plugin 14:25:55 I tend to agree with Vijay 14:26:33 i need to think about it. that doesn't seem obvious to me 14:26:44 ok we can discuss offline 14:26:58 ok. lets take it offline 14:27:04 i tend to disagree at the moment. 14:27:04 ok 14:27:11 :) 14:27:53 #topic third-party testing 14:27:56 any updates on third-party testing? 14:28:38 as i said earlier we have setup ready, have to patch the tempest scenario test and run 14:28:57 There are some errors in import 14:29:00 for tempest 14:29:24 initially it complained could not import subunit is not present, now it is complaining about importing extras 14:29:30 i see some bugs filed in tempest 14:29:41 We are working on setup and gerrit triggers 14:29:51 are you saying you could not setup tempest? 14:30:03 yes 14:30:04 does devstack fail to set it up for you? 14:30:35 i clone devstack , stack.sh, then run_test.sh 14:30:37 this is failing 14:30:43 with the import errors 14:30:54 basically, what third-party test run should do: 14:31:01 it should clone devstack 14:31:22 then create custon localrc, specifying git clone path to the patch on review 14:31:34 then ./stack.sh 14:32:04 run_tests.sh failed for me too for the first time, there were some gcc compilation errors when installing dependencies 14:32:06 localrc should have tempest enabled so /opt/stack/tempest have configured tempest ready to run 14:32:19 Vijay - is is smth you also faced? 14:32:55 enikanorov: We tohught it may be long to setup devstack for each test. Checking the option to patch the same environment each time 14:32:57 Vijay: please contact us if you have issues with setting up tempest 14:33:21 enikanorov: I mean, tear dows, replace code, startup. What do you think? 14:33:56 evgenyf: i think it's better to test agains fresh code. everyhing can change 14:34:01 tempest, nova, neutron 14:34:10 each change can indentify some issue 14:34:41 enikanorov: I mean to change all code. Just code, no configurations 14:34:45 also, I think it's necessary to do more than just post +1 or -1 back. I think authors should be able to see logs 14:35:00 evgenyf: right, the configuration should be the same 14:35:13 I think unstack/stack should be enough 14:35:24 with RECLONE=yes option in localrc 14:35:28 if you reclone repositories 14:35:30 right 14:35:31 enikanorov: Anyhow , we will see if it's possible 14:36:07 ok 14:36:10 stack/unstack is heavy 14:36:11 should we touchbase on the mailing list or IRC 14:36:20 about the tempest seutp? 14:37:16 I could not locate the bug right now. the fix was saying something like adding subunit to requirements.txt 14:37:29 after i did that tempest passed one stage of errors 14:37:32 again FYI today will be a separate irc meeting on third party testing on 22 UTC 14:37:33 ./stack takes 3 minutes on a VM with 4 gig on a modern server 14:37:35 it should be ok 14:38:16 Vijay: sure lets troubleshoot it later. 14:38:30 enikanorov: ok 14:38:32 22 UTC not very convenient for India time :-( 14:38:58 sure enikanorov 14:39:11 22 utc is not convenient for me as well. are you refering to the meeting? 14:39:18 yes 14:39:18 yeah, they changed the time to let folks from japan and China join this time 14:39:20 i was not going to attend since it's too late 14:39:37 it is 3:30 am for me 14:40:22 lets go ahead. i will get in touch with you eugene offline 14:40:29 ok 14:40:31 for resolving the tempest issue. Thanks! 14:40:37 at least reading the logs tomorrow will be useful 14:40:48 evgenyf: any update on L7 rules? 14:41:23 Avishay is on it and change is WIP 14:41:45 left some comments on it today 14:42:08 Avishay is off today 14:42:27 the patch now contains only DB logic 14:42:29 can you send the link on the channel? I think i've missed it 14:42:42 unless I missed smth 14:42:43 enikanorov 14:42:46 sure 14:42:58 sorry, https://review.openstack.org/#/c/61721/4 14:43:21 Yes, It's not end2end yet 14:44:07 thanks 14:44:11 I'll review 14:45:09 lets move to SSL? 14:45:13 enikanorov: thank you 14:45:18 Sure 14:45:36 I hope to commit later today 14:45:57 is there smth on review regarding SSL? 14:46:06 Mark did not approve the concept yet because the security, will continue talking to him later 14:46:57 BTW, updated the WIKI page. 14:47:32 ok, good. 14:48:17 btw, I forgot an important announcement that we will not be keeping meeting on 12/26 and 01/02 14:49:03 regarding passinfo, how are the info passed to servers?