21:03:05 <markmcclain> #startmeeting Networking
21:03:06 <openstack> Meeting started Mon Sep 29 21:03:05 2014 UTC and is due to finish in 60 minutes.  The chair is markmcclain. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:03:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:03:09 <openstack> The meeting name has been set to 'networking'
21:03:19 <markmcclain> mestery is in transit this week, so I'll be filling it
21:03:26 <markmcclain> (fortunately it is a light week)
21:03:40 <dougwig> party time.
21:03:55 <markmcclain> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
21:04:19 <markmcclain> dougwig: haha
21:04:24 <markmcclain> #topic Announcements
21:04:29 <markmcclain> #link https://wiki.openstack.org/wiki/Network/Meetings Release Notes
21:05:19 <markmcclain> We're starting to work on the Juno release notes.  If anything is missing please let us know
21:05:53 <markmcclain> RC1 should be cut very soon
21:06:08 <markmcclain> #topic Bugs
21:06:12 <markmcclain> enikanorov: hi
21:06:40 <markmcclain> #link https://bugs.launchpad.net/neutron/+bug/1374573
21:06:41 <uvirtbot> Launchpad bug 1374573 in neutron "Server hang on external network deletion with FIPs" [Critical,Confirmed]
21:06:54 <markmcclain> armax: you were working on this one, but nobody seemed to pick it up
21:07:03 <markmcclain> seems like this is a release critical bug
21:07:52 <armax> markmcclain: yes, but the change was not deemed acceptable, and I won’t have to look at it today or tomorrow
21:08:15 <rkukura> markmcclain, armax: I did a quick review of armax’s patch this AM, and was concened about the change to use a separate mutex.
21:08:20 <salv-orlando> armax: but is the hang observed in specific or all cases
21:08:55 <armax> salv-orlando: the hang is only observable when deleting an external network with disassociated fip's
21:09:28 <salv-orlando> armax: yes, but it’s not intermittent - everytime you have an ext net with disassociate floating ips it hanfs
21:09:55 <salv-orlando> and by hanging stop processing for all routers on the l3 agent, I guess
21:10:01 <armax> salv-orlando: correct
21:10:10 <markmcclain> ok.. so we'll continue to track it
21:10:13 <armax> salv-orlando: this is a server-side hang
21:10:38 <markmcclain> I think we can cut RC1 and either release note it or target this specific bug for RC2
21:11:02 <markmcclain> Any other release critical bugs the team should be tracking?
21:11:19 <rkukura> armax: If we could eliminate the with_lockmode(‘update’), I think we could also remove the mutex locking.
21:11:29 <salv-orlando> frankly I am looking at review comments and it seems they ended up in argument which goes way beyond the specifc bug being addressed
21:11:45 <salv-orlando> is this bug so deep rooted in the ml2 architecture that we can’t really fix it in an easy way?
21:11:52 <rkukura> salv-orlando: No
21:12:04 <salv-orlando> rkukura: so how should we fix it?
21:12:35 <rkukura> salv-orlando: Not sure, but the mutex was added for a specific purpose, and using a different mutex no longer serves that purpose.
21:13:04 <armax> rkukura: it looks like you got the hang of this, so you should fix it :)
21:13:29 <salv-orlando> rkukura: my question was not about whuy the fix is ineffective, but rather about what would be the proper fix. I would like to release juno with a fix rather than a release note
21:13:45 <markmcclain> salv-orlando: I agree that the deadlock is very troubling
21:13:50 <rkukura> armax: I can take a closer look.
21:13:52 <markmcclain> and would prefer a fix
21:13:57 <salv-orlando> which would basically say “ermm… please try not to do this particular thing otherwise your l3 agent will be gone for good"
21:14:03 <markmcclain> rkukura: thanks for digging into it
21:14:59 <markmcclain> Last call for release blocking bugs…
21:15:50 <markmcclain> #topic Docs
21:15:52 <markmcclain> emagana: hi
21:16:01 <emagana> Hi There!
21:16:32 <markmcclain> #link https://etherpad.openstack.org/p/neutron-docs-juno
21:16:44 <markmcclain> Looks like we need a few volunteers for doc items
21:16:49 <markmcclain> how's the recruitment going?
21:16:58 <emagana> Ok, News on the Docs side. The Networking guide is moving forward #link https://blueprints.launchpad.net/openstack-manuals/+spec/create-networking-guide
21:17:16 <emagana> markmcclain: I will cover that in a bit!
21:17:25 <markmcclain> ok.. cool
21:17:55 <emagana> A bunch of people reach me out to find out the how to review content, well in that BP you will find all the current content (very raw still)
21:18:26 <emagana> Now, we have defined a new process to add content quickly and easier for developers that are NOT familiar with the Docs process
21:18:48 <emagana> Basically, this wiki #link  https://wiki.openstack.org/wiki/NetworkingGuide/TOC
21:18:52 <markmcclain> oh cool… that will be a big help for contributors
21:19:44 <emagana> So, we have identified a couple of Docs folks to help with the translation from the wiki to the Docs (HTML) but we need people filling up the gaps on the wiki
21:20:20 <emagana> The contribution will be recorded as co-author in the gerrit commits
21:20:43 <emagana> WE are going to focus on the Networking Guide and then the Admin Guide will be fixed based no that
21:21:01 <emagana> So, that is actually what is going on right now!.
21:21:14 <markmcclain> good stuff thanks for sharing the changes
21:21:28 <emagana> For the guys leading DVR and L3 HA. Please, make sure that you review those sub-sections.
21:21:42 <emagana> The migration path will be covered in the Operations Guide!
21:21:48 <emagana> I will discuss that in the next meeting
21:22:03 <armax> emagana: can you share links to these reviews?
21:22:24 <emagana> armax: For the networking guide?
21:22:33 <armax> ya
21:23:15 <emagana> #link https://review.openstack.org/#/q/project:openstack/openstack-manuals,n,z
21:23:43 <emagana> Look for networking-guide directory: https://review.openstack.org/#/c/117327/
21:24:04 <armax> emagana: thanks!
21:24:15 <emagana> markmcclain: That is what I have so far
21:24:22 <markmcclain> emagana: thanks for the update
21:24:49 <markmcclain> #topic Sub Team Reports
21:25:13 <markmcclain> Looks like the subteam reports are unchanged from last week, so if you've got something speak up now :)
21:26:20 <dougwig> should we mention the lbaas v2 feature branch and review standards for it?
21:26:38 <markmcclain> dougwig: sure
21:26:56 <markmcclain> so for the feature branch
21:27:07 <markmcclain> cores should review the code to ensure it is correct, but it does not have to be complete
21:27:14 <markmcclain> (ie partial implementations are ok)
21:27:33 <markmcclain> I think the current patch in the series has comments on missing migration information
21:27:51 <dougwig> mostly it's retrofitting to the new non-conditional migrations.
21:27:53 <markmcclain> if we create a note or bug to fix it later, I'd be ok moving
21:27:55 <dougwig> current review list is here: https://etherpad.openstack.org/p/lbaas_reviews
21:28:21 <salv-orlando> at the gerrit level, feature branches can have a different core them can’t they?
21:28:46 <markmcclain> salv-orlando: yes… we can define a different group, but we've been trying to get RC1 out first :)
21:29:16 <salv-orlando> markmcclain: ok - you said “cores” and I thought you meant the standard core team
21:29:26 <dougwig> for now, he does.
21:29:27 <markmcclain> for now those groups are the same
21:29:40 * salv-orlando retracts his question and goes to put his head in shame in the sand
21:29:55 <salv-orlando> whoops no sand… I’ll have then to bang my head against the wall!
21:30:05 <markmcclain> salv-orlando: haha
21:30:17 <dougwig> channel that emotion into some lbaas code reviews.  :)
21:30:22 <markmcclain> dougwig: did I answer your question?
21:30:36 <dougwig> yes, i just wanted it on radar with the neutron cores.
21:30:45 <dougwig> ty
21:31:34 <markmcclain> #info cores should be reviewing LBaaSv2 for feature branch
21:31:51 <markmcclain> Any other subteam reports?
21:32:38 <markmcclain> #topic Kilo Specs
21:33:16 <markmcclain> #link http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/kilo Kilo Specs
21:33:27 <markmcclain> the kilo directory for the specs repo is now open
21:33:41 <markmcclain> #info The template we use has changed since Juno
21:33:49 <markmcclain> #link http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/template.rst
21:34:23 <beagles> yay ascii art
21:34:54 <markmcclain> The repository has been opened for submissions, but we still have lots of work todo on Juno which we should stay focused on
21:35:43 <markmcclain> beagles: everyone's favorite right?
21:36:05 <beagles> markmcclain: vim shines w visual block mode ;)
21:36:30 <markmcclain> The spec tools have been updated to test for the new template, so if you propose using the old template expect a -1 from jenkins
21:37:15 <markmcclain> Also don't forget that Paris summit session ideas are being collected here:
21:37:24 <markmcclain> #link https://etherpad.openstack.org/p/kilo-neutron-summit-topics Neutron summit session ideas
21:38:04 <markmcclain> Any other open discussion items?
21:38:20 <beagles> o/
21:38:31 <markmcclain> beagles: yes
21:38:44 <Sukhdev> markmcclain: Sorry I joined late - when is RC1 being cut and is there RC2 in plan?
21:38:53 <beagles> so I've been looking at doing something about neutronv2/api.py in nova
21:39:20 <markmcclain> Sukhdev: RC1 will be cut very soon.. ideally after we have a fix for the FIP bug
21:39:33 <markmcclain> as for RC2 we are not tracking any bugs for it at this time
21:39:40 <beagles> so far I've more-or-less an island but I know others have also been thinking about this a lot and may have done some work on it already
21:39:46 <Sukhdev> markmcclain: Thanks
21:40:19 <dougwig> what's the state of flavors?  will be re-proposed as is for kilo, or...?
21:40:26 <beagles> most of the process oriented stuff happens in nova - and they are also still focused on juno
21:40:50 <markmcclain> beagles: right I know some Nova folks I've chatted with have wanted to discuss this too
21:40:52 <beagles> but sometime soon things will start rolling
21:40:53 <dougwig> oh whoops, sorry, for some reason i thought we were in open discussion.
21:41:05 <markmcclain> I'm hoping we can get some cross project discussion time set aside for it
21:41:10 * beagles nods
21:41:15 <markmcclain> dougwig: we are in open discussion
21:41:33 <markmcclain> dougwig: yes flavors will be re-proposed for Kilo
21:41:53 <markmcclain> since we didn't have a ready made user for them in Juno without pain for everyone
21:41:56 <dougwig> did we have consensus on the spec at the end of juno, or is there still work there?
21:42:02 <beagles> I unfortunately will not be in Paris, but no doubt there will be others there to bash it about
21:43:05 <markmcclain> dougwig: we've mostly converged on a spec
21:43:20 <markmcclain> just need to reformat it for the new template and clarify a few bits
21:43:33 <markmcclain> enikanorov also has made an initial implementation of it
21:43:39 <blogan> will the spec need to go through the spec review process for kilo?
21:43:59 <markmcclain> blogan: yes… all specs have to go through the process
21:44:18 <blogan> okay, wasn't sure if since this may have already had an agreement if it still needed to
21:44:19 <blogan> thanks
21:44:22 <markmcclain> blogan: fortunately since everyone has discussed it, ensuring consensus should be easy
21:44:29 <blogan> lol
21:44:32 <blogan> famous last words
21:45:02 <beagles> one of the suggestions that was made to me that is looking more attractive all of the time is treating the effort as a sort of enhanced neutron client and implement the nova network stuff in terms of that
21:45:52 <marun> ...and we can roll those enhancements into neutronclient?
21:45:54 <markmcclain> blogan: yep.. I've probably cursed it
21:46:12 <beagles> if it is deemed appropriate, yeah
21:46:18 <dougwig> markmcclain: we just need to throw in some UDP based objections.
21:46:22 <markmcclain> beagles: the neutronclient is one of the issues
21:46:37 <markmcclain> but the general workflow between Nova and Neutron is not efficient at all
21:46:40 <beagles> markmcclain: mmm yeah
21:46:57 <markmcclain> dougwig: haha
21:46:58 <beagles> markmcclain: I've already ran into some of those things in mucking about with some ideas
21:47:28 <markmcclain> also any work we do on the neutronclient should be balanced with the community initiative for the openstacksdk
21:47:36 <beagles> markmcclain: the nova code sometimes is just inefficient, but in other cases it is clearly a slave tot he client
21:47:49 <beagles> markmcclain: mmm.. noted
21:47:59 <markmcclain> I'd hate for the two teams to duplicate work and choose diverging paths
21:48:23 <markmcclain> beagles: agreed
21:49:03 <beagles> markmcclain marun: so in general .. improvements to neutronclient is a net win
21:49:06 <beagles> ?
21:49:44 <marun> beagles: I think we need a better client.  Not just via the cli, but also as a library.
21:50:03 <markmcclain> yes… I expect the improvements to involve a significant refactoring
21:50:32 <beagles> would it be fair to say that the current "library" is nearly 100% driven from cli requirements?
21:50:41 <markmcclain> we also have to pin the CLI to provide backwards compatiblity
21:50:48 <beagles> right
21:51:43 <markmcclain> beagles: actually the current client was just the easiest path to serialize any API call
21:51:58 <markmcclain> I'd argue it does not serve the CLI well either
21:52:16 <beagles> markmcclain: ic
21:52:42 <markmcclain> any other open discussion items?
21:53:48 <markmcclain> ok.. thanks for stopping in this week and see everyone on the ML and IRC
21:53:51 <markmcclain> #endmeeting