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