21:02:16 #startmeeting Networking 21:02:16 Meeting started Mon Sep 16 21:02:16 2013 UTC and is due to finish in 60 minutes. The chair is markmcclain. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:02:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:02:19 The meeting name has been set to 'networking' 21:02:32 #link https://wiki.openstack.org/wiki/Network/Meetings 21:02:42 #topic Announcements 21:03:29 The Openstack Foundation is currently conducting a user survery 21:03:31 #link https://www.openstack.org/user-survey/Login/ 21:03:58 the results from this survey are really important for the community because it gives us good data to help prioritize and shape our planning 21:04:02 hi 21:04:24 #link https://launchpad.net/neutron/+milestone/havana-rc1 21:04:42 We're closing on our first release candidate 21:04:59 Now is the time to focus on testing and bug squashing 21:05:04 With that 21:05:06 #topic Bugs 21:05:14 https://bugs.launchpad.net/neutron/+bug/1211915 21:05:16 Launchpad bug 1211915 in neutron "Connection to neutron failed: Maximum attempts reached" [Critical,Confirmed] 21:05:21 this is our only critical bug 21:05:29 it is still showing up in some gate runs 21:05:58 It is currently unassigned 21:06:08 I know we have a few folks look into it 21:06:24 do we have someone who wants to step be the assignee? 21:06:28 arg, I never did get to it 21:06:49 nati_ueno: did you make any progress? 21:07:13 marun: sorry no progress. it looks like agent udpate has sql issue 21:07:20 it get slow queries 21:07:34 then we got many connections, then we got the error 21:07:44 but I'm not sure how to fix sql yet 21:08:08 I can look at it, the only warning being that I'm off from Th to M so if I don't make progress I'll need to hand it off. 21:08:17 nati_ueno: the agent does not talk directly to the db 21:08:32 the RPC calls are invoking slow queries on the server? 21:08:47 markmcclain: yep. so I mean, agent kicks rpc and server side db call get slow queries 21:09:13 nati_ueno: if you can help me reproduce it shouldn't be that hard to fix 21:09:18 (famous last words) 21:09:22 nati_ueno: have you isolated which queries those are? 21:09:35 marun: I'm going to make you the assignee :) 21:09:36 not yet. I can't repro it in my local yet 21:09:44 markmcclain: ok 21:09:56 marun: Thanks! 21:10:08 nati_ueno: ok 21:10:21 Any other critical bugs the team needs to know about? 21:11:02 #topic API Docs 21:11:04 salv-orlando: hi 21:11:23 * markmcclain forgot to add it to the wiki 21:11:27 hi. Sadly no huge progress on api docs. 21:11:37 Apart from the fact that we have port bindings docs under review 21:11:43 but I still owe the author samples 21:11:43 fwaas api doc being worked on; i just uploaded a new patch: https://review.openstack.org/#/c/45741 21:11:49 great! 21:12:13 We need documentation, I think, at least for allowed address pairs 21:12:18 correct 21:12:28 I thought arosen volunteered last week write those 21:12:52 yup, I did the doc for openstack-manuals for it but not the api doc's yet. 21:13:00 arosen: awesome 21:13:10 do you remember if we have a taker for metering? 21:13:10 I'll bite that off this week 21:13:20 salv-orlando: not yet 21:13:30 * salv-orlando salv-orlando to ensure each API extension is tracked on launchpad with a bug 21:13:54 #action salv-orlando to ensure each API ext is tracked on LP with a bug 21:13:55 #action member:salv-orlando to ensure each API extension is tracked on launchpad with a bug 21:13:57 thanks 21:13:59 official now :) 21:13:59 FYI, bug-fix out for review for VPNaaS API doc, change to size of peer_address attribute. 21:14:20 #topic Docs 21:14:27 fyi/ I just added the link to api-site on the meeting wiki. 21:14:40 amotoki: thanks! 21:15:09 Edgar is out this week 21:15:32 The docs has decided to build a consolidated admin guide 21:15:38 salv-orlando: Don't see doc bug for multiprovidernet 21:15:53 rkukura: i'll bite that one off too. 21:16:09 rkukura: you are right. Indeed the action item markmcclain created is for me to do them 21:16:15 there will be a few movements of the docs, so be on the lookout for suggestions from annegentle and her team 21:16:30 on where some sections might move to 21:16:31 fwaas admin doc is out of WIP and has received reviews: https://review.openstack.org/#/c/44756/ 21:16:36 yes do keep an eye on the review queue 21:16:48 this is with the new structure 21:17:19 SumitNaiksatam: thanks, what we are considering next is moving network-admin-guide into admin-guide-cloud 21:17:32 SumitNaiksatam: so yours is the 0.5 version and we hope to get to 1.0 :) 21:17:37 annegentle: ok 21:17:58 hopefully this will get merged before that! :-) 21:18:54 SumitNaiksatam: yes I think that's best! 21:19:07 annegentle: yay, thanks! 21:19:17 I know rkukura and mestery are collaborating on the ML2 docs 21:19:30 I will focus on reviewing neutron doc this week and test them. 21:19:31 no progress from me yet 21:19:42 Same for me, though hopefully this week we'll get that rolling. 21:20:06 is there room for more help on that rkukura ? 21:20:38 possibly - haven't really started yet, but lets talk 21:20:53 thanks, appreciate it. 21:21:34 Any other docs items to discuss? 21:22:28 #topic Python Client 21:22:40 #info 2.3.1 was released today to PyPI 21:23:34 #topic Horizon 21:24:13 hi. FFE items are good shapre. 21:24:40 The subsequent patch in FWaaS for better navigation under review https://review.openstack.org/#/c/45901/ . 21:25:02 i would like to call for testing for the patch. 21:25:18 SumitNaiksatam: has the FW sub team had a good chance to look at this? 21:25:41 I believe it is a good improvement. The example snapshot is available at the Wiki. https://wiki.openstack.org/wiki/Network/Meetings#Networking_in_Horizon_.28amotoki.29 21:27:08 i will ask FWaaS folks after the meeting. 21:27:46 Let's try to get as many eyes on this week as possible 21:27:59 amotoki: any other Horizon updates? 21:28:14 nothing from me. 21:28:29 amotoki: thanks for the update 21:28:44 #topic Icehouse Design Summit 21:29:22 I want to let everyone know that you can now propose summit sessions 21:29:38 markmcclain amotoki: sorry, had stepped away, i will be testing the new patch from amotoki 21:29:40 #link http://summit.openstack.org 21:29:48 SumitNaiksatam: thanks 21:29:51 SumitNaiksatam: thanks 21:30:04 There is still plenty of time to propose, so write your docs for existing code first :) 21:30:19 A few reminders about summit proposals.... 21:30:55 It is not the first to file. If there multiple proposals for the same topic we'll work form teams around the common interests 21:31:25 this has worked very well for us in the past with LBaaS, VPNaas, and FWaaS being good examples of where the community came together to plan in advance 21:32:06 If you have something that is a better mini topic make sure to make a note in the proposal. We'll reserve some slots for mini sessions. 21:32:21 There is one new wrinkle this time around. 21:32:29 Blueprints and/or etherpads are encouraged 21:32:54 Having one associated with proposal will help your proposal have a better chance at acceptance 21:33:24 it also helps us schedule the sessions around common themes and provide feedback to help shape discussion ebfore we get to Hong Kong 21:34:28 When thinking about topics it is important that we balance shiny features with community features 21:34:52 community features benefit the whole community… recent examples include ML2, metadata 21:35:09 Any questions on proposing for the summit? 21:35:21 I would like to raise a point, perhaps not important, but since you're asking for questions 21:35:23 I noticed in previous summits that in several cases going to summit session with slides just did not work; this is perhaps because a collaborative discussion is very different from a presentation. 21:35:32 should we propose to ban them? 21:35:54 salv-orlando: I'm actually leaning that way 21:36:06 * mestery agrees with salv-orlando and markmcclain on this one as well. 21:36:06 but wanted to discuss a little closer to the summit 21:36:12 ban entirely? 21:36:21 agreed 21:36:32 marun: yeah… slides tend to discourage discussion 21:36:38 i'm confused. are slides not useful for providing an introduction to a topic for discussion? 21:36:41 the point of the ODS is to be collaborative 21:36:54 marun: the ether pad should be the main thing on display, imho 21:36:55 marun: i agree 21:37:00 ah, fair enough 21:37:00 slides = bad 21:37:03 you can have bullets like if they were slides there 21:37:16 If the etherpad has the basic information, I agree with no slides. 21:37:35 slides helps present an idea. 21:37:37 I still have mixed feelings 21:37:38 its easy to preseed the etherpad 21:37:41 how do you capture diagrams in etherpad? 21:37:44 What if we want a diagram? 21:37:47 yeah, what he said. 21:37:59 think in text 21:38:01 Whiteboards? 21:38:05 yeah.. we can work at mechanics a little closer to the summit 21:38:10 I'm not suggesting we want to encourage broadcast sessions, but this black and white thinking is a bit much. 21:38:24 Whiteboards are more collaborative I think, though present some challenges of their own. 21:38:37 but I wanted to plant the seed that we really want to encourage discussion over lecture style sessiosn 21:38:46 -1 to lecture style, for sure 21:39:07 marun: no black and white rules 21:39:21 the core team can work with the proposers 21:39:41 and figure out a good common ground because effective discussion is the most important item 21:39:54 markmcclain: even ether pad could be lecture style, i believe a collaborative session can be had irrespective of the mode of presentation 21:40:09 SumitNaiksatam: agreed 21:41:38 #info Our summit sessions will run Tuesday, Wednesday and Friday 21:41:49 for those planning travel arrangements 21:42:54 We've have a Thursday break to attend sessions for other projects and discuss is open space on any items that spill over their time 21:43:04 Any other summit items? 21:43:24 #topic Open Discussion 21:43:27 will there be any join sessions 21:43:39 garyk: right now we haven't scheduled any 21:43:42 sorry joint sessions - for example replacing nova networking 21:43:49 ok. 21:44:20 but there are few I'd like to see: especially around tempest and returning to migration away from nova-net 21:44:52 Depending on initial reaction, may want the DNRM session to be joint Neutron-Nova to address the compute aspects of NFV 21:45:52 geoffarnold: what is DNRM? 21:46:00 geoffarnold: have you filed already? 21:46:08 geoffarnold: what is NFV 21:46:21 See the blueprint for Dynamic Network Resource Management I posted a couple of weeks ago 21:46:31 gongysh: NFV = network function virtualization 21:46:33 NFV: network function virtualization 21:47:19 Haven't filed a session proposal yet: working with a few others to make it a collaborative proposal 21:47:50 geoffarnold: can u show me the BP url of DNRM? 21:47:59 that seems like a pretty ambitious blueprint. Is the intention to implement in smaller chunks at least? 21:48:27 https://wiki.openstack.org/wiki/Blueprints 21:48:38 Oops - sorry too quick 21:48:45 It also seems to be related to network aware scheduling. 21:48:52 https://blueprints.launchpad.net/neutron/+spec/dynamic-network-resource-mgmt 21:49:30 Can't easily do it in chunks - too many interdependencies. We'll have a demo with code at Hong Kong 21:49:44 ?? 21:49:45 Resource scheduling, not compute scheduling 21:49:56 geoffarnold: some of us have branistroming on the service VM discussion: https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms 21:50:01 Although in the long term they're probably linked 21:50:10 That doesn't sound particularly amenable to iterative development, or of effective reviewer oversight. 21:50:35 geoffarnold: would be great if you can join the discussion 21:50:50 sorry guys i am beat. have a good night 21:50:56 Just for a simple summary, what resources are being dynamically managed? 21:51:01 All, regarding https://review.openstack.org/#/c/37131/. (multiple API worker processes) The three initial patch contributions have come together in to this patch set. There is a Jenkins failure that we don't quite understand. Looks like an older recheck bug. Would anyone be willing to put some eyes on the failure? 21:51:05 g'night gary 21:51:14 I"m looking at the pdf now, but I'm sure someone else may have the question. 21:51:20 garyk: night 21:51:33 Hmm. That blueprint is a couple of weeks after DNRM; a pity it wasn't sync'd 21:51:35 Any other discussion items? 21:51:56 geoffarnold: I'd like to discuss offline when you have the chance. 21:51:56 carl_baldwin: let's discuss offline about that one 21:52:25 markmcclain: Sure, ping me when you have time. 21:52:46 The polling minimization changes still need review (bug/1177973): https://review.openstack.org/#/dashboard/2035 21:53:07 Sure, marun: email me at geoff@geoffarnold.com 21:53:19 geoffarnold: ack 21:53:20 marun: there's been a bit of concern about bug vs feature 21:53:33 markmcclain: really? 21:54:01 markmcclain: Where has that feedback been coming from? 21:54:22 yeah.. can't remember where I saw it on the bug, review or ML 21:54:30 markmcclain: *sigh* 21:54:30 I'll have to dig up the link 21:54:41 I raised the concern 21:54:44 markmcclain: and? 21:54:47 not because I want to piss off people 21:54:54 or to moan, even if I do that a lot 21:54:58 salv-orlando: Would you like to talk to me about it? 21:55:04 salv-orlando: this is the first I'm hearing 21:55:07 just because the bug fix resulted in 4 patches 21:55:15 I think I commented on one review 21:55:21 4 patches with rather large diffs 21:55:29 or perhaps I am wrong and I was looking at other patches 21:55:47 I made sure to make each patch very coherent and to the point. 21:55:52 and salv-orlando commented it on the bug. 21:56:22 *sigh* 21:56:24 marun: I have no problem in reviewing, and letting it merge in RC1 21:56:56 I'm not trying to add a new feature. The point was to make l2 agent performance suck less so developers don't have their machines spinning at idle. 21:57:01 I just raised a question - based on what has been done in previous releases. For other people to comment and make a call 21:57:27 And it's optional - turned off by default. No existing functionality is affected. 21:58:06 Anyway, reviews appreciated. If this isn't deemed useful, sure, it can wait until icehouse. 21:58:55 But I'm going to suggest that pushing back because of the number of patches is a bad idea. 21:59:11 Sure, I could have tried to merge one large patch. But patch coherency is important and should make reviewing easier. 21:59:46 * markmcclain likes small patches vs behemoths 21:59:55 If the patch allows one to run the code in the same sucky way it did, then it should be no problem in terms of being disruptive 22:00:40 It is entirely optional - it's necessary to set minimize_polling = True in the agent config for the new path to be used. 22:00:48 ok.. we're at time 22:01:05 let's take a look at the code and discuss on the review 22:01:10 sound good? 22:01:40 looks good to me. I apologise if I sounded like a bitch moaning over bureaucratic principles 22:01:56 * mestery chuckles silently. 22:02:01 sounds good to me. 22:02:48 salv-orlando: no need to apologize.. it is important to keep a critical eye and understand what's being merged this late in the cycle 22:03:08 ditto that 22:03:46 Thanks to everyone for joining and let's get our docs done since good docs make the user experience better 22:03:57 Have a great week and see everyone on the ML and IRC 22:04:00 #endmeeting