16:02:57 <rkukura> #startmeeting networking_ml2
16:02:57 <openstack> Meeting started Wed Apr 23 16:02:57 2014 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:00 <openstack> The meeting name has been set to 'networking_ml2'
16:03:19 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2 Agenda
16:04:01 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_April_23.2C_2014
16:04:19 <rkukura> #topic Announcements
16:04:49 <rkukura> Design summit sessions for neutron are Wednesday, Thursday, and Friday
16:05:13 <rkukura> I think we had previously been told there were none on Friday, so check your travel plans
16:05:35 <rkukura> Also, the new BP review process is up and running
16:06:15 <rkukura> All BPs targetting juno will need to be reviewed in the neutron-specs project
16:06:33 <rkukura> We’ll get back to these spec reviews later in the agenda
16:06:42 <rkukura> #topic Action Items
16:06:56 <rkukura> no action items from last week, unless I missed something
16:07:14 <Sukhdev> nope - can think of any either
16:07:23 <rkukura> #topic Design Summit Sessions
16:07:48 <rkukura> #link http://summit.openstack.org/
16:08:03 <rkukura> mestery is finalizing the schedule
16:08:48 <rkukura> the plan is to combine the ML2 session proposals into three 40 minute sessions
16:08:52 <emagana> hi everybody! just quite late!!
16:09:06 <rkukura> hi emagana
16:09:50 <emagana> I will try to make this meeting every Wednesday! I have some ideas that I will share with you.. specially on the multi-node testing side .
16:10:10 <Sukhdev> emagana: cool
16:10:25 <rkukura> One session will be on ML2 roadmap, and will include a number of items: extension support, base SDN driver, error handling and resynch
16:10:49 <amotoki_> multinode testing environment has been supported recently in nodepool.
16:11:25 <rkukura> Another session will be on the agent, and will include: modular agent, OVS firewall driver, OVS feature bridges, etc
16:11:37 <Sukhdev> rkukura: won't that be too much to squeeze in one session?
16:12:09 <rkukura> The 3rd session is on hierarchical network topoologize, and includes dynamic segments, VDP, and topology API
16:12:46 <banix> I think we have to do a lot of thinking/discussing/planning ahead of the summit
16:12:49 <rkukura> Sukhdev: I think all 3 sessions have a lot to cover
16:13:10 <rkukura> as banix said, we need to do what we can prior to the summit to make the best use of our time there
16:13:21 <rkukura> so the spec review process is a big part of that
16:14:09 <Sukhdev> One idea is that we can reserve some time on Monday or Tuesday of the summit week to hash out the details
16:14:23 <rkukura> These sessions aren’t really intended for in-depth presentations
16:14:33 <rkukura> Sukhdev: right
16:14:42 <Sukhdev> Hopefully, we all will be there - meeting in person to hash out may be very productive
16:14:48 <rkukura> mestery told me that there will be a “neutron pod” at the summit
16:15:08 <rkukura> this is a table that will be available throughout the week for neutron discussions, etc.
16:15:42 <padkrish> #sukhdev, rkukura# we will be there, but before that should we review each other's presentations and have more discussions either thru conference or webchat?
16:16:29 <rkukura> padkrish: Right, each group of combined topics should try to coordinate how to use the time
16:16:34 <Sukhdev> padkrish: yes, like rkukura said, we use spec review process
16:17:16 <rkukura> usually an etherpad pre-populated with some bullet points is preferred over slide presentations
16:17:36 <rkukura> that way the discussion can be captured
16:18:06 <padkrish> rkukura, sukhdev: Sure, we will start with the spec review, and may even have more in-depth discussion so that when we meet in the summit, we can have a even more productive session
16:18:19 <rkukura> So we should probably get the etherpads for each of the 3 sessions started, and get everyone to dump their key points in there, and then organize
16:18:27 <Sukhdev> padkrish: + 1 to that
16:18:43 <banix> rkukura: sounds good
16:18:59 <Sukhdev> rkukura: excellent idea to get going
16:19:28 <amotoki_> nice idea
16:19:29 <rkukura> #action rkukura to create etherpads for each summit session as soon as schedule is finalized
16:20:01 <rkukura> that’s for the 3 we talked about, of course ;)
16:20:15 <Sukhdev> rkukura: as soon as you create etherpad, please post the link and we can start to update it
16:20:28 <rkukura> Sukhdev: will do
16:20:42 <rkukura> Are there any ML2-related session proposals that we missed?
16:21:18 <Sukhdev> rkukura: there is one http://summit.openstack.org/cfp/details/74
16:21:41 <yamamoto> does this count?  http://summit.openstack.org/cfp/details/138
16:21:55 <rkukura> I’m sure many other session will touch on ML2
16:21:59 <Sukhdev> it is not for ML2, but, I am telling them that we should bring this API in ML2 instead of services
16:22:42 <rkukura> I don’t think either of those two were being grouped into ML2, not sure if mestery plans to give them their own sessions, group them with others, or reject them
16:22:56 <Sukhdev> This is an API for L2 Gateway - hence should belong to ML2
16:23:37 <amotoki_> agree with rkukura. even if the reference implementation is on ML2, it is general to all plugins.
16:23:38 <Sukhdev> It is not scheduled yet
16:24:06 <rkukura> The 3 session are really those things that evolve the existing ML2 plugin and the agents, rather than completely new features - I think those are being scheduled separately
16:25:12 <rkukura> Anything else on the design summit right now before we move on to bugs?
16:25:55 <Sukhdev> banix: is your proposal in one of these three sessions?
16:26:05 <banix> Sukhdev: yes
16:26:18 <Sukhdev> banix: cool - thanks
16:26:21 <rkukura> banix, Sukhdev: Is this the modular agent proposal?
16:26:33 <Sukhdev> rkukura: yes
16:27:01 <rkukura> anything else?
16:27:14 <rkukura> #topic bugs
16:27:50 <rkukura> #link https://bugs.launchpad.net/neutron?field.searchtext=ml2
16:28:38 <rkukura> so the only high priority bug seems to be https://bugs.launchpad.net/neutron?field.searchtext=ml2
16:28:55 <rkukura> Make that https://bugs.launchpad.net/neutron/+bug/1276391
16:29:18 <rkukura> This is my patch that moves port binding outside transactions
16:29:38 <rkukura> Its got a +2 from mestery, but I’ll update it based on comments from rcurran
16:29:56 <rkukura> And I think matrohon is reviewing it as well
16:29:58 <mestery> I think patch is pretty much ready rkukura, nice work!
16:30:33 <rkukura> So nows the time to get any feedback in on it
16:30:38 <HenryG> I will give it another look too
16:30:51 <rkukura> I’ll try to do a hopefully final update late today
16:31:02 <Sukhdev> rkukura: I will give another look as well
16:31:05 <rkukura> Thanks
16:31:10 <irenab> looking at this patch too
16:31:22 <rkukura> There are a number of medium priority bugs
16:31:44 <amotoki_> me too but i am re-studying all workflows of ML2 and have not reached yoru patch so far....
16:32:56 <rkukura> amotoki_: ok, it does change some things, and hopefully the code comments help clarify things, so take a look when you can
16:33:42 <rkukura> many of the medium bugs are marked as in-progress, but a few are triaged or confirmed, so may need owners
16:33:56 <banix> Decision was to rethink the approach for dealing with https://bugs.launchpad.net/neutron/+bug/1227336  and discuss during the summit
16:34:11 <rkukura> Are there any specific bugs anyone wants to discuss?
16:34:28 <vthapar> I had one
16:34:37 <rkukura> banix: Right, that will be one of the key topics in the Roadmap session
16:34:47 <rkukura> vthapar: go ahead...
16:34:52 <vthapar> https://bugs.launchpad.net/neutron/+bug/1263866 - This has some impact on ovs-firewall-driver
16:35:00 <Sukhdev> banix: correct - this is included in one of the sessions
16:35:34 <vthapar> SG driver deletes existing flows and then adds on a port_update. with defer_apply it doesn't work in right order.
16:35:52 <vthapar> it ends up adding new flows before delete all while preferred order is other way around.
16:36:38 <vthapar> it is different from bug's description, but I think if I were to raise different, would end up being duplicate of this in some way
16:37:05 <vthapar> for now am avoiding it by disabling defer apply.
16:38:00 <rkukura> vthapar: what do you suggest for a long term fix?
16:38:17 <amotoki_> I wonder why the situation occurs...
16:38:54 <yamamoto> relying the apply order for correctness sounds too fragile
16:39:00 <vthapar> ability to apply flows in order they were added, maybe a new function defer_apply_on_ordered or an option to force it to use ordered.
16:39:23 <vthapar> yamamoto: I'd say it depends on use case, so better to provide option(s)
16:39:45 <yamamoto> probably
16:40:09 <amotoki_> do we need some locking mechanism to ensure only one ovs-vsctl/ofctl runs at one time?
16:40:40 <rkukura> Maybe this is something that should be addressed as part of the agents summit session, since that touches on modularing things, the ovs-firewall-drver, and making sure drivers’ flow rules don’t stomp on each other
16:40:50 <amotoki_> according to the bug report, it seems deferred_apply_off is not enough..
16:41:21 <rkukura> s/modularing/modularizing/
16:41:54 <vthapar> the bug's focus is on concurrency while mine is on order of a single set of operations.
16:42:14 <asadoughi> vthapar: indeed, i think you should file a new bug
16:42:16 <vthapar> can raise a separate bug if it would be better way to go about it
16:42:46 <vthapar> another thing I can offer is, if we come up with different solutions help test them out for different use cases.
16:43:09 <rkukura> so does it make most sense to get this initial fix in, then deal with a better solution as a separate bug?
16:43:27 <asadoughi> rkukura: +1
16:44:05 <rkukura> so lets review the current fix so it can merge
16:44:15 <rkukura> any other bugs to discuss?
16:44:33 <vthapar> rkukura: +1
16:45:08 <amotoki_> we will receive more bugs as icehouse is shipped. I see some questions in the general list.
16:45:13 <rkukura> #topic Spec Reviews
16:45:30 <rkukura> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z
16:46:34 <rkukura> there are 24 specs in review already!
16:46:42 <rkukura> many of these touch on ML2
16:47:04 <rkukura> So I encourage everyone to review these and get their comments/questions in
16:47:58 <amotoki_> I think there are some ML2 specific topics to be covered in spec reviews.
16:47:58 <rkukura> My personal view is that we should not rush to approve specs too quickly, so there is time to get feedback
16:48:22 <rkukura> amotoki_: yes, specifics you have in mind?
16:48:25 <amotoki_> I see a comment how to handle port binding from rkukura.
16:48:49 <amotoki_> I agree with the comment.
16:49:35 <HenryG> What do we do if we want to comment on an approved spec, or propose updates to an approved spec?
16:50:00 <rkukura> mestery: Can you respond to HenryG’s question?
16:50:11 <Sukhdev> Any new BP which could impact the existing ML2 drivers should be discussed in this meeting before approving - would you agree?
16:50:27 <mestery> HenryG: That's a good question. I think it's fair to talk to the spec writer or comment in code reviews. Thoughts?
16:50:31 <rkukura> It is certainly possible to propose patches to existing approved specs
16:51:31 <amotoki_> ML or IRC discussion may be better for such cases. Comments on merged reviews are sometimes not noticed.
16:51:52 <rkukura> Sukhdev: I agree - anyone who noticed one of these should add it to the upcoming meeting agenda in under this topic
16:52:20 <HenryG> Thanks everyone, sounds good
16:52:25 <rkukura> amotoki_: I agree comments in the already-merged gerrit review will likely be missed
16:53:07 <rkukura> I’d suggest that if the implementor(s) discover significant design changes are needed, they should propose a patch to the spec for review
16:53:47 <amotoki_> rkukura: +1
16:53:53 <HenryG> rkukura: +1
16:53:56 <rkukura> But I’d hate to bog things down with reviews for small changes, and we still need to allow iterative approaches
16:54:19 <Sukhdev> rkukura: +1
16:54:22 <rkukura> I think we all should just use our best judgement
16:55:01 <rkukura> If a code review sees that the code is competely out of sync with the spec, they can -1/-2 the code review and ask for the spec to be updated 1st
16:55:26 <rkukura> anything else on spec reviews - 5 minutes left?
16:55:41 <rkukura> #topic Code Reviews
16:56:16 <rkukura> I don’t have anything specific here on the agenda - does anyone have any reviews they want to bring to people’s attention?
16:56:58 <rkukura> #topic Open Discussion
16:57:22 <rkukura> anything else, or are we done for today?
16:57:25 <emagana> does anyone test multi-node with VLANS using devstack? All is working fine for me with default either GRE or VXLAN tunnels but the not for the VLANs, I am worry if we are not testing this.
16:57:52 <yamamoto> is there any design doc of modular agent, or it’s merely a vague idea at this point?
16:58:17 <emagana> Tunnels are great but many OpenStack users still use VLANs (provider networks)
16:58:25 <rkukura> yamamoto: Good question - banix, any chance of a spec to review prior to the summit on this?
16:58:30 <banix> yamamoto: no design doc yet. will be sending out email and update etherpad
16:58:41 <nlahouti> emagana: I tried it but VM creation fails
16:58:56 <yamamoto> as there seems to be a consensus to block further dev of ofagent for it, i don’t want to wait for the summit
16:58:58 <amotoki_> banix: thanks for taking this. I am intersted in this topic and help you.
16:59:07 <banix> yamamoto: i also noticed your comment and will talk to you in this regard
16:59:13 <nlahouti> emagana: got traceback with vif_port
16:59:21 <banix> amotoki_: great. will reach out to you. thanks.
16:59:24 <rkukura> emagana, nlahouti: Does single-node devstack with VLANs work?
16:59:42 <emagana> nlahouti: VM are created on my side but the data traffic is not working between nodes
16:59:42 <padkrish> emagana: I tried around 3 weeks back with master and didn't work straight out. Apart from manually adding the physical port to br-ethx, i also had to clear the iptable rules in order to get it to work
16:59:53 <emagana> rkukura: Yes, single node works fine
17:00:27 <rkukura> Sounds like a bug should be filed against devstack
17:00:29 <nlahouti> emagana: I was able to create network but vm creation has issue.
17:00:30 <rkukura> time is up
17:00:40 <rkukura> #endmeeting