21:04:07 #startmeeting Networking 21:04:08 Meeting started Mon Sep 23 21:04:07 2013 UTC and is due to finish in 60 minutes. The chair is markmcclain. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:04:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:04:11 The meeting name has been set to 'networking' 21:04:30 #link https://wiki.openstack.org/wiki/Network/Meetings 21:04:44 #topic Announcements 21:05:20 The release candidate will be cut soon 21:05:38 hi, sorry for being late 21:05:45 when will the rc be cut? 21:06:16 I'm hoping for late this week 21:06:25 ok, thanks 21:06:44 great, it's almost over then 21:06:53 yes 21:07:12 At this point in time we should be focusing on release critical bugs 21:07:16 * salv-orlando is undecided whether to feel scared or relieved 21:07:26 like 121915? 21:07:39 yes 21:07:53 which leads us into our next topic 21:07:55 #topic Bugs 21:08:04 #link https://bugs.launchpad.net/neutron/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Confirmed&field.status=Triaged&field.status=In+Progress 21:08:28 current we three critical open bugs 21:08:29 https://bugs.launchpad.net/neutron/+bug/1211915 21:08:32 Launchpad bug 1211915 in neutron "Connection to neutron failed: Maximum attempts reached" [Critical,Confirmed] 21:08:49 maru n was working on this one 21:09:02 he's off today, so I'll follow up with him we he returns 21:09:12 this bug started popping up again in the gate recently 21:09:31 We've also have this one: 21:09:31 https://bugs.launchpad.net/neutron/+bug/1227091 21:09:33 Launchpad bug 1227091 in neutron "ml2 fails to bind lbaas VIP" [Critical,In progress] 21:09:37 gongysh is working on it 21:09:48 and this one: 21:09:49 https://bugs.launchpad.net/neutron/+bug/1229394 21:09:50 Launchpad bug 1229394 in neutron "VPN Migration does not specify correct plugin" [Critical,In progress] 21:09:56 salv-orlando: is working on the last one 21:10:05 any other critical bugs the team needs to know about? 21:11:47 Any other bugs the team needs to discuss? 21:12:35 From my side, all the bugs I would really see merged for RC1 already already on gerrit 21:12:46 not sure if we want to cover bug #1228735 21:12:48 Launchpad bug 1228735 in neutron "add lockmode to neutron context" [Undecided,In progress] https://launchpad.net/bugs/1228735 21:12:49 but I'm not sure about the bug for removing auto-schema generation 21:13:01 * salv-orlando leaving the stage to armax 21:13:19 salv-orlando: think auto-removal to is too risky? 21:13:37 it has a dependency on puppet-openstack otherwise smokestack will fail 21:14:03 I pushed the patch into neutron-puppet but I'm not sure if it will make it in time 21:14:21 ok.. smokestack shouldn't be blocking the gate 21:14:42 it votes on the check chain 21:14:51 right it will vote on a check 21:14:54 but not a verify 21:15:00 Idk if it's ok to approve a patch down voted by smokestack 21:15:13 my understanding is that is ok 21:15:19 also, then smokestack will start to -1 every patch which uses neutron if we merge this change 21:15:22 I'll confirm the situation with infra 21:15:25 k 21:15:43 armax: you proposed a patch https://review.openstack.org/#/c/47706/ 21:16:02 markmcclain: this is a pointer to the puppet patch https://review.openstack.org/#/c/47854/ 21:16:03 yup 21:16:14 this adds lockmode support on the context 21:16:53 my only concern is that lockmodes have slightly different behaviors across the database backends 21:17:12 to some degree that is already handled by sqlalchemy 21:17:37 in that, for instance, select for update is ignored for sqlite db backends 21:17:40 I thought we have still seen reports on differences between mysql and postgres 21:18:04 sqlite has lots of consistency issues so we'll ignore for now 21:18:05 sorry, I am late.. bad jet lag.. :-) 21:18:22 that said, having the context expose the functionality or calling sqlalchemy directly with a specified lock mode makes no actual difference 21:18:30 as far as db abstraction is concerned 21:18:43 underlying details are leaked regardless 21:18:50 but I see what you mean 21:20:21 I do think this change has merit 21:20:26 I am ok if the change needs to churn a little more 21:20:42 I have cycles to shepherd it into a RC 21:20:58 how frequent and serious is the bug it tries to solve 21:21:21 I think I've seen it in the past - it was rather infrequent and most importantly non critical (i.e.: nothing crashed) 21:21:26 well the race condition I was trying to address is there 21:21:33 this is the race: https://review.openstack.org/#/c/46563/ 21:21:59 sorry, I was referring to the race condition bug of course 21:22:01 I have never seen it in practice without staging it 21:22:19 arosen: is that the one we've been sporadically seeing in the past? 21:22:23 it looks the same to me 21:22:32 yea i think so. 21:22:54 that said there are other places in the db_plugin where we lock for update 21:23:12 kevin, who created the bug was able to reproduce it consistently 21:23:44 ok.. let's review the patches 21:23:54 I'll track them as possible inclusion into the RC 21:23:57 I was trying to make a simpler point. If the bug is not critical, and we don't have strong consensus behind current approach, defer 21:24:02 but let's move discussion to gerrit 21:24:05 yup 21:24:07 agreed 21:24:46 my feeling is that these will help and at worst they won't make the probably any worse 21:25:01 markmcclain: agreed 21:25:22 I don't feel super happy about adding lock_mode to context, but I am not either opposed to that 21:27:02 ok.. I'll track them and we can discuss in gerrit 21:27:06 any other bugs? 21:27:15 I'm good 21:27:28 #topic API Docs 21:27:33 aloha 21:27:54 https://bugs.launchpad.net/openstack-api-site/+bugs?field.tag=netconn-api 21:28:02 bugs for all the extension have been added 21:28:14 I am reviewing the FWaaS docs, hopefully we should merge them soon 21:28:21 great 21:28:24 We need takers for 3 bugs 21:28:36 dkehn: can you help with the Extra DHCP api docs? 21:28:40 bug #1229384 21:28:41 Launchpad bug 1229384 in openstack-api-site "Document neutron allowed-address-pairs extension" [Medium,Confirmed] https://launchpad.net/bugs/1229384 21:28:51 bug 1226280 21:28:53 markmcclain, yes I can 21:28:54 Launchpad bug 1226280 in openstack-api-site "Neutron API: Extra DHCP opts extension" [Undecided,New] https://launchpad.net/bugs/1226280 21:29:00 dkehn: thanks 21:29:13 bug 1229389 21:29:14 Launchpad bug 1229389 in openstack-api-site "Document Neutron metering extension" [Undecided,New] https://launchpad.net/bugs/1229389 21:29:19 so 1226280 is taken 21:29:20 markmcclain, I'll talk to you later for what that means and were to put them 21:29:36 dkehn: salv-orlando can help you too 21:29:41 great 21:30:02 1229384 I thought arosen was working on that one 21:30:26 arosen: can you confirm you can take that bug? 21:30:29 Yea, i;ll post the patch shortly. Sorry got caught up with some other stuff last week. 21:30:46 great 21:30:53 sorry again for the delay.... 21:31:08 arosen: we're still pre-RC so you're good 21:31:55 salv-orlando we can work offline to find an assignee for the metering API docs unless someone here wants it 21:32:41 markmcclain: let's take it offline 21:33:12 thanks for ensuring we didn't miss any of the ext api docs 21:33:18 anything else? 21:33:23 that is all 21:33:27 there are changes in l3 (service plugin) and agent scheduler extension. i will file them as bugs and take them. 21:33:47 amotoki: great.. thanks 21:33:48 are they API changes? 21:34:14 AFAIK, there are no change in API but extension names are changed. 21:34:33 the main goal is to check them. 21:34:34 right. good point. 21:36:04 #topic docs 21:36:11 emagana: hi 21:36:17 I was away for a week, but I am seeing ML2 discussions are going on (rkukura) and also that the FWaaS was merged (snaiksatam) 21:36:33 filed bug 1229237 for ml2 config reference, will file a few more now that consolidation merged 21:36:34 Launchpad bug 1229237 in openstack-manuals "Update configuration reference for neutron ml2 plugin" [Undecided,New] https://launchpad.net/bugs/1229237 21:36:37 same status for metering docs than for API, we need to document it 21:36:55 Ok 21:37:10 https://bugs.launchpad.net/openstack-manuals/+bug/1202967 21:37:11 Launchpad bug 1202967 in openstack-manuals "Add Neutron l3 metering agent" [Medium,Confirmed] 21:37:37 ok.. let's work offline to get a taker for it 21:37:47 I know you've been gone… anything else? 21:38:02 markmcclain: I also read the latest neutron guide and there are few things that dont make sense for Havana 21:38:32 markmcclain: I will file bugs for that and fix them by myself 21:38:48 emagana: this is the recently merged guide? 21:39:39 a dumb question on docs from me: shall we push changes to openstack-cloud-admin, openstack-network-admin or both? 21:39:46 markmcclain: no, the one before. 21:39:56 salv-orlando: the openstack-network-admin got deleted in a merge today 21:40:22 salv-orlando: everything found happy new homes 21:40:30 markmcclain: I will do a review on the merged one to validate changes 21:40:32 annegentle: thanks. I think Diane tried to explain that to me… but as I said, sometimes I just unplug my brain 21:40:39 salv-orlando: hee 21:41:20 Any other doc items? 21:41:21 thanks to the admin doc project members who reviewed the FWaaS admin doc (if they are here)! nice feedback and turnaround in the past one week towards getting patch merged!! 21:43:08 nothing from me! just Thank Anne, Diane and everybody involved on the new guide! 21:43:29 yeah.. I'm happy the new guide has become a reality 21:43:47 #topic FWaaS 21:44:04 During reviews something as bubbled up that got missed early on 21:44:18 firewall are current per tenant and not per router 21:44:50 markmcclain: thats per documented design all along 21:45:04 markmcclain: that was pointed out in review 21:45:21 Sumit has all the answers 21:45:37 right.. just wanted to make sure folks are aware of this 21:45:59 because I know it has caught more than a few folks by surprise 21:46:02 markmcclain: the plan, as I've been told, is to have a concept of zones as l3 domain groupings 21:46:15 but this was obviously not in Havana plans 21:46:17 btw, this is not a constraint of the API 21:46:24 or the resource model 21:46:44 this is a constraint of the reference implementation (moreso the agent/driver) 21:47:02 that said, this also needs service insertion framework support 21:47:11 so yes, this was not part of the Havana plans 21:47:24 ok.. just need to make sure we're consistent on messaging 21:47:30 So is the VPN service doing something wrong by binding to a routeR? 21:47:33 since the VPNaaS is per router 21:47:36 * salv-orlando now ducks and runs 21:48:26 the right model is to support service insertion 21:48:51 markmcclain: we will make sure that this is documented 21:49:07 in the context of the firewall reference implementation 21:49:11 ok 21:49:36 SumitNaiksatam: agree 21:49:55 amotoki: thanks, i hope it addresses your concern that you pointed on the bug 21:50:11 the bug and fix was created to address your concern 21:50:32 https://review.openstack.org/#/c/47659/ 21:50:44 thanks. my only concern was there seems a few consensus about it. 21:51:21 now we all seem to be in the page. 21:51:39 long term we'll revisit the one firewall per tenant concept 21:51:48 makes sense 21:51:58 markmcclain: yeah, this is certainly not a long term goal 21:52:04 so documenting that this is a Havana restriction works 21:52:22 #topic Horizon 21:52:35 https://review.openstack.org/#/c/45901/ 21:53:16 looks like the Horizon UI update is still needs for testing? 21:53:25 how confident are we that it will land? 21:53:40 SumitNaiksatam: thanks for testing. i am not why you failed to create a firewall. 21:53:57 amotoki: yeah, may not be an issue with your patch 21:54:20 however my setup worked without your patch 21:54:23 i will file it as a bug to clarify its priority and discuss with other horizon cores in tomorrow meeting. 21:54:50 have to bail, will check the log 21:55:00 SumitNaiksatam: hmm.... i will rebase a patch and let you know. 21:55:17 thanks for your help. Input from FWaaS team is important. 21:55:26 amotoki: thanks 21:55:49 there is another topic. enikanorov is working on adding provider support in lbaas. 21:56:08 amotoki: will that be granted an exception? 21:56:20 it is just a small change and i already discussed in the meeting last week. 21:56:25 ok 21:56:26 it is handled as a bug. 21:57:01 all from me. 21:57:17 amotoki: thanks for the update 21:57:23 #topic Deprecation 21:57:54 The ML2 team has been busy ensuring feature parity with the existing OVS and linuxbridge plugins 21:58:52 We've discussed deprecating the monolithic OVS and linuxbridge plugins before. 21:59:38 The plan would be to release Havana with a note indicating that the OVS and linuxbridge plugins are deprecated and that new deployments should use ML2 21:59:51 do we need to clarify how to migrate from OVS/linuxbridge to ML2 before Havana release? 22:00:05 amotoki: I think that seems like a reasonable thing to do, yes. 22:00:11 The code for the plugins would still be in the tree 22:00:27 so we have a little bit of time to clarify the migration to ML2. 22:00:45 i think so too. 22:01:00 The deprecation warning just allows us to remove the code in Icehouse 22:01:20 NOTE: we won 22:01:54 we won't actually remove the code until to mid-to-late Icehouse 22:02:16 thoughts or concerns? 22:02:24 makes sense to me 22:02:37 markmcclain: sounds like a good plan, so the warning will be in the code itself? or documentation? I think in both, right? 22:02:59 both 22:03:03 The plan makes sense to me as well. 22:03:37 markmcclain: Perfect! 22:04:53 Ok.. I send out an email to the ML to warn of the impending change 22:04:59 #topic Open Discussion 22:05:18 We're a little late on time.. any items that need to brought up? 22:05:31 markmcclain: I'd like to talk about IPAM offline 22:05:44 just a quesiton. does anyone usually test with postgresql? We sometimes have bugs related to postgres. 22:06:12 amotoki: I believe smokestack will run against postgres 22:06:17 I have once :) 22:06:30 if you're finding bugs please file them 22:06:55 most of the time they're small simple fixes 22:06:58 markmcclain: from what I gathered today smokestack uses postgres if you're not running neutron 22:08:10 * markmcclain makes note to test potential RC candidate against postgres 22:08:52 roaet: we'll have to talk a bit later as I have to head out right after this 22:09:18 markmcclain: absolutely, whenever you're available 22:09:19 thank you 22:10:00 All… I'm happy that the docs are progressing very well and our RC will be cut sometime late this week or next Monday. 22:10:05 Have a good rest of the week. 22:10:09 #endmeeting