14:00:34 <mestery> #startmeeting networking_ml2
14:00:35 <openstack> Meeting started Wed Aug  7 14:00:34 2013 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:38 <openstack> The meeting name has been set to 'networking_ml2'
14:00:53 <mestery> rkukura, apech, rcurran, Sukhdev, asomya, matrohon: here?
14:00:58 <rkukura> hi
14:01:11 <rcurran> hi
14:01:13 <mestery> I think today will be a short meeting
14:01:22 <mestery> #link https://wiki.openstack.org/wiki/Meetings/ML2 Agenda
14:01:48 <mestery> The ML2 wiki page is coming together now.
14:01:51 <mestery> #link https://wiki.openstack.org/wiki/Neutron/ML2 ML2 Wiki Page
14:02:00 <apech> hi
14:02:02 <safchain> hi
14:02:14 <feleouet> hi
14:02:33 <mestery> Keep adding content to the ML2 wiki page.
14:02:47 <dandrushko> is it a right place where i can report about issue with  ML2 + devstack setup?
14:02:48 <mestery> We'll want to start documentation as well soon. rkukura and I will coordinate that soon.
14:03:03 <mestery> dandrushko: Yes, it's on the agenda, we'll get to it soon.
14:03:11 <apech> I added some more details to the ML2 wiki on mechanism drivers. appreciate any feedback
14:03:13 <dandrushko> thank you! waiting for this
14:03:19 <mestery> apech: Thank you!
14:03:31 <mestery> #topic Discussion Items
14:03:39 <mestery> The first item is something asomya brought to my attention
14:03:44 <mestery> DB migrations in the context of ML2.
14:03:52 <mestery> asomya: here?
14:04:05 <asomya> mestery: yup
14:04:30 <mestery> asomya: Can you summarize the issue?
14:05:08 <asomya> So is the general idea here to let each mechanism driver manage it's own models but still reuse a common neutron database?
14:05:44 <rkukura> yes, as long as we can make that work
14:06:55 <asomya> how will we implement alembic migration scripts for ML2 when any number fo drivers can work simultaneously? we'll need migrations scripts per friver?
14:06:57 <asomya> *driver
14:07:50 <asomya> Also will the neutron-db-manage script be able to generate migrations for ML2 drivers?
14:08:25 <rkukura> So far, I think we've been generating migration scripts with all drivers loaded
14:08:48 <mestery> So will we just assume that is the default going forward then for migrations?
14:09:27 <asomya> rkukura: So we get tables for all drivers every time?
14:09:54 <rkukura> I think that is the case so far - is it worth trying to optimize this?
14:10:21 <asomya> as longs as the table names don't overlap, i think that's acceptable for now
14:10:58 <mestery> Anything else on DB migrations?
14:11:33 <rkukura> if someone wants to optimize the migration scripts, that would be great, but doesn't seem super high priority
14:11:56 <mestery> rkukura: An Icehouse item for sure at this point. :)
14:12:30 <rkukura> we'd need to address adding/removing drivers within an existing ml2 deployment, which might be tricky
14:13:29 <mestery> Moving on to the next agenda item: devstack with ML2 MechanismDrivers.
14:13:33 <mestery> I wrote something up for this.,
14:13:45 <mestery> #link https://docs.google.com/document/d/1vvfey4SCFA5Ih9e6VUdjnRAVj6YIusfXlbPT8yxVOvY/edit?usp=sharing ML2 MechanismDrivers in devstack
14:13:50 <mestery> Would appreciate reviews.
14:14:10 <mestery> I think it will let arbitrary MDs work with devstack with per-MD config added to the ml2 config file in a nice, easy way.
14:14:47 <mestery> I plan to implement this today and push out an initial review, as I know people are to the stage where this would be useful for their MDs.
14:15:02 <apech> mestery: sounds great, look forward to it
14:15:30 <asomya> mestery: could you give comment permissions in that page?
14:15:31 <mestery> apech: Thanks! Let me know if you see something which doesn't look good, otherwise I'll hopefully get a review pushed out later today for people to test with.
14:15:33 <rkukura> some of this is already addressed I think
14:15:39 <mestery> asomya: Yes.
14:15:49 <mestery> rkukura: which part?
14:16:04 <rkukura> I'll review in detail, looks like Q_AGENT needs some work
14:16:27 <rkukura> ml2-portbinding will also be adding mechanism drivers for the agents
14:16:48 <mestery> rkukura: So we may have to rework devstack a bit with that as well. I'm happy to work with you on that.
14:17:49 <rkukura> ok
14:17:52 <mestery> As long as we're talking devstack, I'd like to also highlight this bug:
14:18:00 <mestery> #link https://code.launchpad.net/bugs/1208557 ML2 MechanismDriver devstack bug
14:18:02 <uvirtbot> Launchpad bug 1208557 in devstack "The ML2 devstack integration doesn't set mechanism_drivers correctly" [Undecided,In progress]
14:18:07 <mestery> I have a fix for this out already
14:18:13 <mestery> Here: https://review.openstack.org/#/c/40260/
14:18:26 <mestery> It was an oversight on my part when I did the recent ML2 devstack changes.
14:18:41 <mestery> dandrushko: Maybe this is what you're hitting?
14:20:09 <dandrushko> mestery: reading this
14:20:30 <mestery> dandrushko: If not, please share what's happening with devstack and ML2.
14:20:47 <dandrushko> my issue rises during upgrade script SQL
14:21:05 <dandrushko> particularly during 2032abe8edac -> 52 c5e4a18807, LBaaS Pool scheduler
14:21:42 <dandrushko> sql statement refers to table "agents" which wasn't created during  previous steps
14:22:08 <dandrushko> more accurately foreign key refers to this table
14:23:46 <dandrushko> 511471cc46b_agent_ext_model_supp.py - here this table should be created
14:24:21 <dandrushko> but in upgrade function there is string
14:24:22 <dandrushko> if not migration.should_run(active_plugin, migration_for_plugins):         return
14:24:24 <rkukura> looks like that file list the plugins, but not ml2
14:24:52 <dandrushko> so table is not created here.
14:26:45 <mestery> rkukura: So is the correct fix to modify the migration script here? Or that one shoudl just list * to cover all the plugins?
14:27:20 <mestery> Actually, that migration leaves a few other plugins out as well I notice.
14:27:49 <rkukura> Are services like LBaaS now a separate plugin? If so, I'm not sure why they should depend on the core plugin
14:29:31 <mestery> rkukura: I don't know the answer to that now.
14:29:43 <mestery> But this issue seems like something we should bringup on the mailing list to get other eyes on it.
14:29:52 <mestery> dandrushko: Can you send an email to openstack-dev on this please?
14:29:57 <rkukura> agreed
14:29:58 <dandrushko> sure!
14:30:02 <mestery> thanks!
14:30:07 <mestery> Lets move on now.
14:30:11 <dandrushko> thank you!
14:30:14 <mestery> #topic Blueprint Updates
14:30:25 <mestery> #link https://blueprints.launchpad.net/quantum/+spec/ml2-portbinding ML2 Port Binding
14:30:37 <rkukura> slow start, but making progress
14:31:08 <rkukura> I'll try to get some code in review, possibly WIP, by the weekend
14:31:21 <mestery> rkukura: Great, thanks! We'll all jump on the review as well.
14:31:33 <mestery> rkukura: So as part of htis work, are you moving LB and OVS to MechanismDrivers?
14:32:04 <rkukura> I'll be adding drivers for them, but not sure if I'll move the RPC stuff into the drivers (yet)
14:32:11 <mestery> rkukura: OK.
14:32:27 <rkukura> drivers will mainly deal with picking segment and vif_type
14:33:12 <mestery> OK, thanks for the updates rkukura. Any questions for port-binding?
14:33:53 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/ml2-multi-segment-api ML2 Multi-Segment API
14:34:19 <mestery> rkukura: This one is assigned to you as well now I see. :)
14:34:33 <rkukura> I noticed that, but didn't do it
14:34:51 <rkukura> Are you planning to work on it, or was someone else?
14:34:52 <mestery> I think markmcclain did that recently. Did you need someone else to take this one on given port binding?
14:34:57 <mestery> I think I was going to take a crack at it.
14:35:01 <mestery> Can you change it to me for now?
14:35:05 <rkukura> sure
14:36:07 <mestery> I'll see if I can get a start on it this week yet.
14:36:18 <rkukura> great!
14:36:22 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/ml2-typedriver-extra-port-info ML2 TypeDriver extra port info
14:36:26 <mestery> ZangMingJie: here?
14:36:31 <ZangMingJie> ye
14:36:35 <mestery> cool
14:36:46 <mestery> I see you pushed out a new review
14:37:05 <mestery> I'll review this one today yet.
14:37:18 <mestery> I think we agreed to move forward with this BP, so I'll approve it as well.
14:37:29 <ZangMingJie> I'll push another workable patch later this day
14:37:35 <mestery> ZangMingJie: Thanks!
14:37:47 <rkukura> I recall we wanted to look at how this relates to the multi-segment-api
14:38:43 <ZangMingJie> I have removed segment_id and physical_network from network table
14:39:12 <rkukura> where are they now?
14:39:17 <ZangMingJie> and moved them to type driver store instead as we disscussed last week
14:40:22 <ZangMingJie> now the network table contains id segment_uuid and type
14:41:25 <rkukura> the driver changes aren't in the WIP patch yet, right? Will they be in todays?
14:41:34 <ZangMingJie> yes
14:41:57 <rkukura> So drivers can store whatever fields they need?
14:42:13 <ZangMingJie> yes, and pass them to agents
14:42:28 <rkukura> And the multi-segment-api can just expose those as dicts for each segment?
14:42:40 <ZangMingJie> I think so
14:42:58 <rkukura> sounds good in theory!
14:43:57 <mestery> OK, lets move on to the next items on the agenda.
14:44:04 <mestery> #topic Open ML2 Bugs / BPs
14:44:16 <mestery> We already discussed this devstack bug https://review.openstack.org/#/c/40260/
14:44:21 <mestery> Hope to get it approved today and merged.
14:44:53 <mestery> Is matrohon here?
14:45:16 <feleouet> no, he's ooo for a couple of weeks
14:45:29 <mestery> feleouet: OK, thanks!
14:45:53 <mestery> Any updates on either L2 Population (https://blueprints.launchpad.net/quantum/+spec/l2-population) or GRE/VXLAN tunnels with the same ID (https://bugs.launchpad.net/neutron/+bug/1196963)
14:45:55 <uvirtbot> Launchpad bug 1196963 in neutron "Update the OVS agent code to program tunnels using ports instead of tunnel IDs" [Wishlist,In progress]
14:46:41 <safchain> About l2 population, I'll try to submit a first WIP version by the end of the week
14:46:50 <mestery> safchain: OK, great!
14:47:18 <mestery> #topic Ported MechanismDriver Updates
14:47:25 <mestery> Sukhdev: Arista update?
14:47:38 <feleouet> and on my side, I may follow on matrohon efforts on bug/1196963
14:47:49 <apech> we should be posting our code for review this week
14:47:50 <mestery> feleouet: thanks
14:47:54 <mestery> apech: Cool!
14:47:55 <apech> it's all working, just doing some internal review
14:48:27 <mestery> rcurran: Cisco update?
14:48:42 <mestery> Cisco Nexus update ... :)
14:48:54 <rcurran> trying to get devstack running w/ our nexus switch
14:49:15 <rcurran> devstack issues, not ml2 related
14:49:29 <mestery> rcurran: OK, if you're still hitting issues, ping me after the meeting, me and/or asomya can get you running there.
14:49:40 <rcurran> ported code over to new file format ... btw
14:49:42 <HenryG> rcurran: or me
14:49:48 <rcurran> drivers dir
14:49:49 <mestery> HenryG: Of course. :)
14:49:56 <mestery> rcurran: OK, cool!
14:50:26 <mestery> asomya: OpenDaylight MD update?
14:51:03 <asomya> mestery: Good progress on ODL, should have it working by the wne dof hte week
14:51:14 <asomya> *by the end of the week :)
14:51:37 <mestery> asomya: Thanks!
14:51:55 <mestery> I don't see Luke Gorrie here, but his Tail-F NCS review is being updated regularly: https://review.openstack.org/#/c/37647/
14:52:11 <mestery> #topic Open Discussion
14:52:18 <mestery> Anything else ML2 related this week from anyone?
14:52:52 <rcurran> vendor_config topic?
14:53:04 <mestery> Ah, thanks rcurran.
14:53:11 <mestery> That was the email I sent to the list right?
14:53:16 <rcurran> yes
14:53:37 <rcurran> so are you thinking that each vendor would have their own *.ini file also?
14:53:38 <mestery> So it seems like everyone wants MD config to be in separate config files, is that right?
14:53:44 <mestery> rcurran: I think so, yes.
14:54:00 <rcurran> fine by me
14:54:11 <asomya> +1
14:54:13 <apech> sounds good to me
14:54:23 <rkukura> that gets kind of messy for things like systemd units that launch the server
14:54:44 <mestery> rkukura: Yes, agreed. But distributions could add the config into a single file themselves if they wanted, right?
14:54:54 <mestery> I was going to do that for devstack in fact to keep devstack simple.
14:54:59 <rkukura> they kind of need a fixed set of config file names to pass on the command line
14:55:12 <rkukura> that might make sense
14:55:43 <rkukura> I missed the email thread, but see it now
14:55:46 <mestery> I'll get my devstack patch out as an example at least.
14:55:53 <mestery> rkukura: Cool, respond with your concerns please.
14:56:10 <mestery> OK, anything else?
14:56:13 <rkukura> ok
14:56:35 <mestery> We've got 2 weeks to get reviews pushed out before the feature freeze.
14:56:40 <mestery> Lets see what we can get done in that time!
14:56:53 <mestery> Thanks for everyone's efforts on ML2 so far! Lets keep the momentum going!
14:56:58 <mestery> #endmeeting