15:05:37 #startmeeting neutron weekly meeting 15:05:37 Meeting started Fri Aug 7 15:05:37 2015 UTC. The chair is edwarnicke. Information about MeetBot at http://ci.openstack.org/meetbot.html. 15:05:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:05:37 The meeting name has been set to 'neutron_weekly_meeting' 15:05:45 #topic Rollcall 15:05:50 Please #info in :) 15:05:54 #info edwarnicke 15:06:40 #info ijw 15:06:56 #info yapeng 15:06:59 #info yamahata 15:07:00 #info agupta 15:07:23 armax: Are you here ;) ? 15:07:29 yes I am 15:07:33 mestery: Are you here? :) 15:07:37 Could you guys #info in :) 15:07:40 #info armax 15:08:02 Cool... rollcall... going once, going twice... 15:08:10 Sold 15:08:16 #topic Agenda Bashing 15:08:31 #link https://wiki.opendaylight.org/view/NeutronNorthbound:Meetings <- agenda page for this meeting 15:08:58 #info arieln 15:09:15 welcome ariein :) 15:09:36 Do folks have things they want to add, remove, or reorder from the agenda, or should we just start walking through it? 15:10:46 Last call for agenda bashing 15:11:00 #topic Action Items from the last meeting 15:11:24 First three are for regXboi: 15:11:31 regXboi to send out reminder email on Thursdays with link to draft agenda 15:11:32 regXboi to consult with GBP folks about bug 3968 and why they are calling isXXX() methods directly 15:11:32 regXboi to update Trello Board bug list 15:11:40 regXboi: Have you joined? 15:11:46 Hi all 15:12:07 sigh 15:12:18 apologies folks 15:12:36 the honest truth is I lost track of time working on the lathe 15:13:09 regXboi: No worries... we just got to your action items from here: https://wiki.opendaylight.org/view/NeutronNorthbound:Meetings 15:13:11 :) 15:13:19 is the meeting running? 15:13:22 I see it is 15:13:23 regXboi: Yes 15:13:26 so... #1 is done 15:13:31 #2 is still open 15:13:31 regXboi: God help us all I've been running it 15:13:36 #3 is done 15:13:37 #chair regXboi armax flaviof 15:13:37 Current chairs: armax edwarnicke flaviof regXboi 15:13:43 #6 is done 15:13:49 that's my update :) 15:13:55 * mestery lurks 15:13:55 #info 15:14:03 #action regXboi to consult with GBP folks about bug 3968 and why they are calling isXXX() methods directly 15:14:09 * edwarnicke notices that mestery #info's mysteriously :) 15:14:15 #info regXboi (late and covered in sawdust) 15:14:25 I've done #2 (updating dependencies on mdsal in the release plan) 15:14:35 #info flaviof 15:14:36 #link https://wiki.opendaylight.org/view/NeutronNorthbound:Beryllium_Release_Plan#Expected_Dependencies_on_Other_Projects 15:14:57 flaviof - have you had a chance to look at what deprecating the northbound GETs would do to things? 15:15:14 regXboi: heh... no, sorry. 15:15:17 * regXboi is no longer in favor of deprecation, at least until we work out some other things 15:15:26 flaviof: no worries - ^^^^ 15:15:31 FLAVIOF! 15:15:32 :) 15:15:33 * flaviof was in pto till today after summit. 15:15:36 regXboi: You want to take over driving? 15:15:36 Welcome back my frined 15:15:39 * mestery hugs flaviof 15:15:42 mestery: LOL 15:15:47 I guess 15:15:52 * edwarnicke deeply approves of folks recharging with PTO :) 15:15:56 mestery's in heat again 15:15:58 mestery: ty 15:16:03 actually - I'm on half day today 15:16:05 :) 15:16:10 ijw: You're just jealous you're less than half as awesome as flaviof 15:16:11 anyway 15:16:12 :) 15:16:16 #topic Be 15:16:26 (as in beryllium (which I still can't spell) 15:16:28 Boys boys... do we need a smack talk section of the agenda? ;) 15:16:40 regXboi: I just use Be 15:16:45 #info M1 deadline was 7/30 15:16:50 edwarnicke: apparently not, it takes care of itself 15:16:54 #link https://wiki.opendaylight.org/view/NeutronNorthbound:Beryllium_Release_Plan draft project plan 15:17:02 #info We need a final document contact name - volunteers? 15:17:09 * regXboi waits for the crickets 15:17:23 * edwarnicke subtly unleashes the cricket hoards 15:17:42 * regXboi notes the resounding silence 15:18:08 #action regXboi, edwarnicke, flaviof to find a document contact vict.... volunteer 15:18:25 mestery: Could you #info silence for us again ;) 15:18:34 #topic New items for Be 15:18:42 yea - shiny stuff! 15:18:53 #info L2gateway - 15:19:01 #link https://git.opendaylight.org/gerrit/#/c/24598/ l2GW patch set 15:19:15 I've looked at it and had some nits, but it's a very good first step 15:19:28 great progress, folks :) 15:19:45 thanks ! 15:19:48 #info regXboi is pleased with what he sees there 15:19:57 regXboi: Do we have a link to the neutron docs for the l2gateway api? One of the things I like to do is see how close we are to it :) 15:20:14 edwarnicke: we do 15:20:15 Sangeeta: can you help edwarnicke and #link in the docs? 15:20:25 armax: ^^^^^ 15:20:47 #link https://github.com/openstack/networking-l2gw/blob/master/specs/kilo/l2-gateway-api.rst 15:20:53 but it may be patchy 15:20:57 #undo 15:20:57 Removing item from minutes: 15:21:07 #link https://github.com/openstack/networking-l2gw/blob/master/specs/kilo/l2-gateway-api.rst l2 gateway neutron API 15:21:28 (sets context in the minutes) 15:21:35 best is to look at the extensions code 15:21:41 i am new to irc din't get actually whats needs 15:21:43 armax: LOL 15:21:51 please take a look folks :) 15:22:04 Sangeeta: no worries, just watch and learn as we go :) 15:22:15 ijw: What people do gets done. Sangeeta is doing the work, so its getting done :) 15:22:21 :-) 15:22:21 Sangeeta: Welcome, happy to have you join us :) 15:22:25 #info Multi OS region proposal from HP 15:22:36 #link https://lists.opendaylight.org/pipermail/neutron-dev/2015-August/000260.html initial email of proposal 15:22:50 looking at this, I'm really thinking this is a separate project 15:23:23 regXboi: Can we talk more about that 15:23:29 * edwarnicke pauses to re-review the thread 15:23:31 The logic is reasonable and they're not the first people to say they want it, but there's no suitable API to Openstack itself that you could turn into ODL calls 15:23:38 edwarnicke: sure 15:23:53 ijw is correct 15:24:00 regXboi: I don't quiet follow how this is a separate project 15:24:03 regXboi: Could you say more? 15:24:13 so here's the problem 15:24:26 you are doing something to nit ODL clouds together 15:24:35 ODL clouds, or OS clouds? 15:24:43 both 15:24:58 well... I'll say ODL clouds, because you aren't doing anything at the OS level 15:25:00 is ODL neutron project scope including interfacing with multiple neutron servers or openstack instances? 15:25:05 regXboi: Fair enough :) 15:25:12 yapeng: that is what we are discussing 15:25:14 regXboi: You were saying? 15:25:36 my opinion is that the project's scope doesn't include the logic of trying to tie together multiple OS regions 15:25:57 Talking to multiple neutron servers in the same region (i.e. HA) is part of the scope 15:26:18 I'd agree with that - the OS instances are separate. The ODL instances are not, in that proposal, though I'm not sure I would recommend that in general 15:26:34 regXboi, agreed. 15:26:35 er part of our scope 15:26:38 regXboi: Lets dig into that though 15:26:49 regXboi: Because while I agree with the 'nitting together isn't in our scope' part 15:26:55 regXboi: I think I'm coming to a different conclusion 15:27:02 edwarnicke: say more 15:27:06 My current thinking is this: 15:27:13 We don't nit together anything in neutron-northbound anyway 15:27:15 The ODL are fedrated. The OS are seprated. 15:27:18 The providers do that 15:27:42 I would be annoyed as a cloud deployer if I set up two clouds to be independent failure domains and had their faite tied together by their network controller 15:27:57 So neutron-northbound's part of supporting this sounds to me like just being able to reliably receive from multiple logical OS instances, and hand off that info in a deciferable way to the providers 15:28:05 stitching together is their problem 15:28:08 regXboi: Does that make sense? 15:28:24 edwarnicke: up until the "so ..." statement, I'm on board 15:28:31 but my reaction is the exact opposite 15:28:38 ijw: While I don't disagree with you... thats a deployment design decision by the cloud deployer.... people are allowed to do things we think aren't all that smart ;) 15:28:46 So I would expect multiple network controllers with their own scope (their own DCs, or cloud instances) and a means of negotiation 15:29:13 edwarnicke: indeed, but I don't have to work on what I don't think is smart and I can encourage other people to work on it a different way too ;) 15:29:16 ijw: I can see the use case for why you would want to do what is being suggested though 15:29:28 ijw: Amen to that 15:29:37 having ODL receive from multiple OS regions means that we *have* to take some level of the stitching together role on ourselves, because we can no longer be *truly* transparent 15:30:12 because since the two OS regions *are* truly independent, we have to take some protective steps 15:30:18 So my point is that while that multiple-NBI case is valid it's probably not the one I would choose for the use case given - I would instead make ODL instances that talked to each other 15:30:20 ijw: But I think the discussion here is a little different... in that its more a discission of 'Is this work that makes sense that we'd take in the neutron-northbound' rather than 'Will we choose to do this work'... if someone wants to do the work, does it well, and we decide to take it, it goes in 15:30:36 regXboi: Say more about the non-transparency... because I don't see it yet 15:30:39 apologies if I sounds as clueless as usual 15:30:42 but do we have more context behind the email proposal? 15:31:01 armax: What kind of more context are you interested in? :) 15:31:26 well…it’s mentioned that we want to connect openstack instances over l2 15:31:27 * edwarnicke is the king of clueless, armax will always sound smart by comparison :) 15:31:36 folks - I'm going to budge 15 more minutes for this, because we have other things to get to 15:31:41 er budget, not budge 15:31:50 budge works too 15:31:56 I encourage the discussion, but we have other proposals to consider 15:32:15 but a Neutron network can be a provider network, a tenenat network, an external network 15:32:19 armax: Thank you for that comment, it got me reading more closely this line "Allow neutron L2 network to expend beyond a single openstack instances." 15:32:30 https://lists.opendaylight.org/pipermail/neutron-dev/2015-August/000262.html is more context 15:32:30 they have IP spaces associated to them 15:32:35 and other properties 15:32:43 Need to be two seperated ODL clusters as it need to support two diffrenet data-center multi sites 15:32:43 Which makes clear that the point we are discussing is not the point the author was making 15:33:01 #link https://lists.opendaylight.org/pipermail/neutron-dev/2015-August/000262.html provides more context to this request 15:33:08 #info lots of discussion - see the logs for details 15:33:12 ijw: thanks 15:33:24 regXboi: Perhaps the better question to ask them is what they think needs to happen for an L2 network to extend beyond a single openstack instance... because I can't see a way to do that that doesn't (as you say) put us in the stitching business... but they may have a clever idea there ;) 15:33:52 if I have two entirely distinct domains that we want to connect at l2, we got to factor in what happens at L# 15:33:53 L3 15:34:07 edwarnicke, ijw: the context email actually makes my case for this being a separate project 15:34:12 armax: I suspect they want to use tunnels for overlays... 15:34:18 regXboi: Looking 15:34:19 because it's two ODLs, two OSs, two .... 15:34:27 regXboi: it changes the NBI but it equally changes a lot of other things 15:34:28 and yes, they want VxLAN 15:34:54 arieln: Are you Ariel from the thread? 15:34:55 but the IP’s spaces must be carefully crafted 15:35:03 yes 15:35:09 armax: Yes, and don't get me started on the mac space ;) 15:35:16 arieln: Excellent :) 15:35:21 * ijw finds edwarnicke's dried frog pills 15:35:22 edwarnicke: well that too 15:35:27 arieln: Could you help us understand some of these questions? 15:35:47 * edwarnicke has finally completely missed ijw's reference 15:35:48 so, for instance, do we intend to expose this all the way to tenants? 15:36:02 or we restrict this to provider networks only? 15:36:17 I like to think of things in simple steps 15:36:18 where things may be slightly more controlled? 15:36:24 I do ot think it change the openstack API as of today it beyhond a single OS 15:36:27 armax: the way I read the proposal is that horizon, et.al. are unaware of all of this 15:36:39 Can be ODL API 15:36:41 arieln: uh, what? 15:36:57 And it seems to me, that allowing multiple OS instances to connect, and in some way marking with an OS-instance-id is withing the realm of doability (not expressing an opinion yet on advisability at this point) 15:37:08 armax: tenants would want to be able to make use of a stitching service, ime, but generally at a higher level than they can communicate to either Openstack alone - which implies Openstack provides an admin-level interface that a higher-level API can use and co-ordinate across both ends 15:37:10 But when it comes to the stitching 15:37:14 That's complicated 15:37:57 arieln: I think I'm getting a better picture in my head of what you are asking for 15:37:59 Agreee with ijw 15:38:21 arieln: Question... what allows you to correlate neutron networks from the two OS instances, and how do you insure mac address uniqueness? 15:38:35 I've yet to be convinced this is anywhere close to in scope 15:38:50 in fact, the more this discussion goes on, the less convinced I become 15:39:06 It's not, really - it can't be solved by code here and nowhere else - which means that while this discussion is interesting we're ratholing 15:39:10 You need to map the names to a third entity in the mapping in each OS. 15:39:14 regXboi: I hope that wasn’t my fault 15:39:21 arieln: How? 15:39:23 regXboi: but I don’y mind you think it is 15:39:24 armax: no... ijw nailed it 15:39:32 ijw rocks 15:39:35 MAkeing sure MAC are in the space of OS config 15:39:45 same as L2network 15:39:48 armax: because this can't be solved by code here and nowhere else, this is outside our scope 15:39:51 Can we conclude with where we *should* take the discussion? I'd like to see this discussed, just not here and now 15:40:10 Honestly openstack-dev is not a bad place 15:40:17 regXboi: well, true, this is not just a Neutron Northbound project alone 15:40:26 ijw: +1 with a modification 15:40:35 ijw: arieln Would you mind taking this back to the thread to get a little better understanding of some of these issues here... regXboi might be correct that this is out of scope for us (the stitching part makes me nervous too)... but I'd like to get a better picture, and even if regXboi is right, I'd like to look at how we can leverage neutron-northbound so 15:40:35 you don't have to reinvent the wheel :) 15:40:59 ijw: I'd like to take the openstack and above piece to openstack-dev and the ODL piece to discuss 15:41:15 * regXboi notes there are 5 more minutes on the budget 15:41:18 We do have to invent an API - and honestly that is where I would start it, which is why I suggested openstack-dev 15:41:20 regXboi: As long as we keep the existing thread context on the ODL side, I'm down 15:41:20 ijw: +1 15:41:42 arieln: How do you feel about this, does it feel like its moving in a productive direction to you? 15:42:04 We can take it offline and go over the point raise 15:42:36 Also I commend https://blueprints.launchpad.net/neutron/+spec/cloud-edge-networking to you (an old Neutron spec I wrote that might provide some ideas) 15:42:52 ok thanks 15:43:06 regXboi: Next up? 15:43:11 #info Should networking-ODL be re-written? should it become a monolithic plugin? where should it live? 15:43:42 my answers are yes, don't care, and don't care (so long as my concerns are addressed :) ) 15:43:54 yes I think it should be rewritten 15:43:59 I am sure ijw would add ‘should neutron northbound be re-written too’, no? 15:44:13 armax: that's for later 15:44:17 ah 15:44:18 #link http://sched.co/3yTL Experiences using ODL with Neutron/OpenStack - Wojciech Dec 15:44:23 sorry I jumped the gun 15:44:25 I asked Wojciech to make slides available, but I am not sure if that has happened. 15:44:50 I wouldn't necessarily say it has to be a monolithic plugin - it probably can't interact with the other ML2 drivers, but one advantage of being ML2 is that other people can write things that are not L2 that interact with it (which was an old problem) 15:44:56 We need to look at each issue indivudually. I think some are known issues (armax, mestery?), and were just not added to 15:44:57 bugzilla/launchpad. 15:44:58 ML2 is working on task-flow to address status synching. Can we leverledge that? 15:45:08 Net to net conclusion was that networking-odl needs to be looked as an integral piece of the neutron northbound project. 15:45:27 I suppose they are seeing similar issues 15:45:33 flaviof: I see the slides as a PDF there 15:45:38 But that's jumping ahead. My issue is that the current ODL code suffers from HA problems and multitasking problems and I think we should consider a redesign of the protocol from that perspective 15:45:41 We should rewrite as a core plugin 15:45:41 https://wiki.opendaylight.org/view/NeutronNorthbound:2015Summit#Material_from_July_2015_ODL_Summit 15:45:43 Not an ML2 driver 15:45:45 edwarnicke: got link? 15:45:52 well... I agree that it should be rewritten 15:45:55 Why do we need the abstraction ML2 provides? Doesn't ODL want to own the world here? 15:45:55 Meh 15:46:05 but I think the folks that *do the work* get to choose how it should be rewritten :) 15:46:14 i hear from folks like mlemay on this 15:46:16 I think agupta beat me to it :) 15:46:21 Guys 15:46:23 Lets break this down 15:46:27 edwarnicke: agupta: ty 15:46:31 Because I think we have three discussion here 15:46:45 1) Should odl-neutron transition from being an ML2 driver to a full plugin 15:46:46 Ahh I got named ! 15:46:50 ;) 15:46:55 as for 1 15:46:56 #link https://wiki.opendaylight.org/view/NeutronNorthbound:2015Summit#Material_from_July_2015_ODL_Summit Experiences with Neutron & ODL Slides 15:46:57 #link https://wiki.opendaylight.org/view/NeutronNorthbound:2015Summit#Material_from_July_2015_ODL_Summit slides in background of this discussion 15:47:02 2) Where should odl-neutron live? Do we want to migrate it to neutron-northbound at ODL 15:47:03 um edwarnicke, that isn't #1 15:47:13 3) Stuff we have to do to fix HA/scalability 15:47:27 edwarnicke: If you never want it tested, then definitely yes for #2 15:47:28 My sense is that #1 and #2 are simpler discussions, and so my bias is to figure those out first :) 15:47:42 so, if you look at the agenda 15:47:44 mestery: Could you say more? :) 15:47:50 #3 is a separate topic 15:47:52 Hey Kyle how is it going? 15:47:55 edwarnicke: Yes: The CI for ODL has never worked with OpenStack 15:47:57 flaviof: ^^^ 15:47:58 so it's off the table right now 15:48:02 OK, so let's start with #1 15:48:03 And no one has ever helped us fix it 15:48:05 Other than flaviof and I 15:48:13 * regXboi glares at mestery 15:48:14 mestery: I hear you 15:48:15 By keeping the driver on the OpenStack side 15:48:18 We get CI for free 15:48:25 Makes no sense to move it to ODL 15:48:25 BUT 15:48:33 OK, let's start with #2... 15:48:35 Yes 15:48:37 Yes I also want a nuage-like plugin.. Makes things easier for full fledged controllers.. No harm intended to the ML2 work though. 15:48:40 mestery: Is that CI working though? My sense is that its had a lot of challenges 15:48:41 the bigger question for 1) is: what does moving away from ml2 buy us, and what do we lose? 15:48:41 ijw: Yes 15:48:53 edwarnicke: If you want challenges, try getting it working on the ODL side 15:49:03 So can I suggest it's not about where the source lives, particularly, the problem is who's responsible for it 15:49:04 ok folks.... I'm going wrap my shoe on the table here 15:49:05 All the challenges are due to things unrelated to the infra 15:49:10 let's back up a minute 15:49:13 Moving it to ODL would introduce an entirelly new set of challenges 15:49:14 we jumped to #2 :) 15:49:14 to be the biggest loss is the easy of migration from agent-based to controller-based architecture 15:49:17 I would suggest that we combine the teams for maintaining it and the NB part of ODL 15:49:20 mestery: I plead ignorance on that point, as I have not thus far contributed to those efforts, and I know you have (and many thanks) 15:49:26 Bah 15:49:33 It's pointless to even consider moving it IMHO 15:49:42 on the better note, there is a CI that does similar work and is part of the openstack networking-odl: gate-tempest-dsvm-networking-odl 15:49:45 I think regXboi is wise to try to walk through these in order... because I think #1 is easier than #2 ;) 15:49:55 edwarnicke: Wrong 15:49:55 #2 is easier 15:49:56 #2 I am not usre I even understand what it means 15:50:01 It's pointless to move it. Any questions? 15:50:14 Guys... lets start with #1 15:50:17 There is actually less than zero benefit to moving it 15:50:22 mestery: it is one of these "who is going to do the work things...." 15:50:40 regXboi: No, it's not. It makes no sense to move it out at all. 15:50:44 at least my opinion on *BOTH* #1 and #2 is it is a "who is going to do the work things...." 15:50:49 Someone needs to tell me *what benefit* there would be to moving it. 15:50:54 regXboi: then arguably we're offering advice to whoever picks up the baton 15:51:03 ijw: bingo 15:51:20 Guys.. could we talk about the ML2 to plugin (#1) as it (hopefully) is less charged :) 15:51:34 So, #1: it's a valid point but there's currently no great cost to having an ML2 plugin right now, so let's assume that this is not a terribly urgent need and move on for the moment 15:51:34 but does the move imply a more fundamental change in the code, programming language etc? 15:51:38 it’s unclear to me 15:51:41 if somebody steps forward and says they are willing to do #1, we'll give advice, but *whoever* is doing the work gets final say 15:51:51 ijw: We are doing a *bit* more than that on #1... as there's the question of acceptability of the work... but I dont disagree that someone has to do the work :) 15:52:12 on #2, I lean more towards mestery's point, because I *don't* see how CI is going to work if we move the code 15:52:26 edwarnicke: Why do you keep saying #1 is less charged? I'm saying you have not presented anything useful on #2, thus it's easier on that one unless there is a reason. 15:52:34 and so somebody has to *guarantee* that CI will work and that they will handle care and feeding of it 15:52:35 edwarnicke: For one, I expect that one will fall out of who does the work. 15:52:41 i think we have to stop looking at networking-odl and nn as 2 projects 15:52:46 Define 'move the code' - as I say, here the question seems to be more one that we from this side actualy take responsibility for its quality 15:52:52 Where it lives is entirely secondary 15:52:53 flaviof: Also a good point 15:53:07 flaviof: today, the are separate projects 15:53:08 flaviof++, the point I was making in 10 words 15:53:33 regXboi: they look like they are... but one is meaningless w/out the other 15:53:58 it just happens that 1/2 lives in neutron as a plugin as the other is part of odl. 15:54:09 regXboi: in the future they'll probably also be separate projects too - but the *people* should be the same 15:54:12 So... on the pro-side (and please note, I'm not advocating anything yet... I am trying to sort this out in my head) having two components this tightly coupled in the same place allows for a single patch to make changes to the wire protocol cleanly, and I think there's a lot of sense we need to do a bunch of work there wrt HA and scalabilty (not taking an 15:54:13 position on the rightness and wrongness of that sense) 15:54:17 flaviof: that's *not* entirely true 15:54:34 I don’t understand how the move would work 15:54:35 regXboi: how so? is nn of any value w/out neutron? 15:54:46 if one would be kind enough to elaborate what it means 15:54:49 edwarnicke: if only the Openstack people didn't care about backward compatibility that would be fine, but they do so it's not 15:54:50 * mestery goes to deprecate the existing networking-odl plugin 15:54:55 today Neutron needs a core_plugin set to work 15:54:56 historically, there have been other ODL plugins that talked to NN 15:54:58 armax: Do not feel bad, we are in the 'talking it out stage'... so I'm not sure anyone really fully understands yet 15:55:02 You can't upgrade ODL and Openstack in the same instant 15:55:05 and if that’s ml2, it needs a mech_driver to work 15:55:08 only historically, mind you 15:55:18 edwarnicke: I feel great 15:55:20 er wait - I said that wrong - OS 15:55:32 but I sense I am not useful to this discussion if I don’t understand the premise 15:55:36 and the assumptions 15:55:37 armax: Are you commenting on #1 (the ML2 driver vs plugin) discussion? 15:55:45 armax: lol 15:55:56 armax: As I said, part of this discussion is fleshing all of that out ;) 15:55:59 you guys go from #1 to #2 and back like hummingbirds 15:56:08 I am not so fast 15:56:08 lol 15:56:11 armax: Good point 15:56:12 Guys 15:56:16 Could we focus on #1 for a while 15:56:18 * ijw craps on armax's head 15:56:25 Yea would be better to go at it item by item 15:56:25 * mestery gives up 15:56:27 I learned to read only a week ago 15:56:31 OK, #1: why is it a good idea to move? 15:56:44 um... #1 isn't about moving 15:56:49 ijw: No, #1 is Ml2 -> plugin 15:56:50 ijw: what does 'move' mean? 15:56:56 regXboi: it’s a separate move 15:56:57 ah... ok 15:57:21 edwarnicke: yes, I am aware of that - why is a good idea to move to being a plugin? 15:57:33 as for #1 I think that both places for the ODL integration have pros and cons 15:57:36 folks, I really don't have any skin in the discussion ... I want to know "who is volunteering to do it" 15:57:44 armax: list three 15:58:00 three of what? 15:58:02 regXboi: why volunteer to do it if you can't see the reason for doing it? 15:58:08 armax: pros and cons 15:58:28 ijw: if I there isn't someone to write the code, then the discussion is empty 15:58:28 right, on #1: i would like to hear more on whay that is neeed; for sake of completeness 15:58:40 the biggest con I see to be part of ml2 is that we carry a baggage we might not want 15:58:52 but that baggage at the same time is flexibility we may want 15:59:08 armax: Can you say more about the flexibility? 15:59:18 armax: What flexibility is it buying us? 15:59:26 armax: the issues with sync/etc.. are they pertinent to ml2? 15:59:32 flaviof: no? 15:59:36 flaviof: nope 15:59:52 ack. my reason to ask is that I see a bit of confusion on 16:00:01 flaviof: ml2's mech driver structure helps highlight them but they'd be there regardless 16:00:05 known issues and why / what that is related to mls. 16:00:11 edwarnicke: the flexibility is given by the fact that we can run multiple l2 technologies at the same time 16:00:21 ml2. it makes ml2 a 'bad' think when in fact it has nothing to do with that. 16:00:22 armax: OK, is there any other flexibility? 16:00:38 edwarnicke: so for instance we can have built-in openvswitch and odl running smoothly side by side 16:00:48 today the Neutron world is agent-based 16:00:58 armax: Who in their right mind would do that? 16:01:00 armax: in the case of a controller (ODL) that could use a network in arbitrarily complex ways I don't think that's a massive benefit - but on the other hand it's not an argument to change either 16:01:01 armax: Has anyone ever done that? 16:01:01 armax: let me put on my operator hat 16:01:10 ok I can type now.. sorry guys 16:01:12