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