15:05:37 <edwarnicke> #startmeeting neutron weekly meeting
15:05:37 <odl_meetbot> 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 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:05:37 <odl_meetbot> The meeting name has been set to 'neutron_weekly_meeting'
15:05:45 <edwarnicke> #topic Rollcall
15:05:50 <edwarnicke> Please #info in :)
15:05:54 <edwarnicke> #info edwarnicke
15:06:40 <ijw> #info ijw
15:06:56 <yapeng> #info yapeng
15:06:59 <yamahata> #info yamahata
15:07:00 <agupta> #info agupta
15:07:23 <edwarnicke> armax: Are you here ;) ?
15:07:29 <armax> yes I am
15:07:33 <edwarnicke> mestery: Are you here? :)
15:07:37 <edwarnicke> Could you guys #info in :)
15:07:40 <armax> #info armax
15:08:02 <edwarnicke> Cool... rollcall... going once, going twice...
15:08:10 <edwarnicke> Sold
15:08:16 <edwarnicke> #topic Agenda Bashing
15:08:31 <edwarnicke> #link https://wiki.opendaylight.org/view/NeutronNorthbound:Meetings <- agenda page for this meeting
15:08:58 <arieln> #info arieln
15:09:15 <edwarnicke> welcome ariein :)
15:09:36 <edwarnicke> 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 <edwarnicke> Last call for agenda bashing
15:11:00 <edwarnicke> #topic Action Items from the last meeting
15:11:24 <edwarnicke> First three are for regXboi:
15:11:31 <edwarnicke> regXboi to send out reminder email on Thursdays with link to draft agenda
15:11:32 <edwarnicke> regXboi to consult with GBP folks about bug 3968 and why they are calling isXXX() methods directly
15:11:32 <edwarnicke> regXboi to update Trello Board bug list
15:11:40 <edwarnicke> regXboi: Have you joined?
15:11:46 <dneary> Hi all
15:12:07 <regXboi> sigh
15:12:18 <regXboi> apologies folks
15:12:36 <regXboi> the honest truth is I lost track of time working on the lathe
15:13:09 <edwarnicke> regXboi: No worries... we just got to your action items from here: https://wiki.opendaylight.org/view/NeutronNorthbound:Meetings
15:13:11 <edwarnicke> :)
15:13:19 <regXboi> is the meeting running?
15:13:22 <regXboi> I see it is
15:13:23 <edwarnicke> regXboi: Yes
15:13:26 <regXboi> so... #1 is done
15:13:31 <regXboi> #2 is still open
15:13:31 <edwarnicke> regXboi: God help us all I've been running it
15:13:36 <regXboi> #3 is done
15:13:37 <edwarnicke> #chair regXboi armax flaviof
15:13:37 <odl_meetbot> Current chairs: armax edwarnicke flaviof regXboi
15:13:43 <regXboi> #6 is done
15:13:49 <regXboi> that's my update :)
15:13:55 * mestery lurks
15:13:55 <mestery> #info
15:14:03 <regXboi> #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 <regXboi> #info regXboi (late and covered in sawdust)
15:14:25 <edwarnicke> I've done #2 (updating dependencies on mdsal in the release plan)
15:14:35 <flaviof> #info flaviof
15:14:36 <edwarnicke> #link https://wiki.opendaylight.org/view/NeutronNorthbound:Beryllium_Release_Plan#Expected_Dependencies_on_Other_Projects
15:14:57 <regXboi> flaviof - have you had a chance to look at what deprecating the northbound GETs would do to things?
15:15:14 <flaviof> 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 <regXboi> flaviof: no worries - ^^^^
15:15:31 <mestery> FLAVIOF!
15:15:32 <mestery> :)
15:15:33 * flaviof was in pto till today after summit.
15:15:36 <edwarnicke> regXboi: You want to take over driving?
15:15:36 <mestery> Welcome back my frined
15:15:39 * mestery hugs flaviof
15:15:42 <flaviof> mestery: LOL
15:15:47 <regXboi> I guess
15:15:52 * edwarnicke deeply approves of folks recharging with PTO :)
15:15:56 <ijw> mestery's in heat again
15:15:58 <flaviof> mestery: ty
15:16:03 <regXboi> actually - I'm on half day today
15:16:05 <regXboi> :)
15:16:10 <mestery> ijw: You're just jealous you're less than half as awesome as flaviof
15:16:11 <regXboi> anyway
15:16:12 <mestery> :)
15:16:16 <regXboi> #topic Be
15:16:26 <regXboi> (as in beryllium (which I still can't spell)
15:16:28 <edwarnicke> Boys boys... do we need a smack talk section of the agenda? ;)
15:16:40 <edwarnicke> regXboi: I just use Be
15:16:45 <regXboi> #info M1 deadline was 7/30
15:16:50 <ijw> edwarnicke: apparently not, it takes care of itself
15:16:54 <regXboi> #link https://wiki.opendaylight.org/view/NeutronNorthbound:Beryllium_Release_Plan draft project plan
15:17:02 <regXboi> #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 <regXboi> #action regXboi, edwarnicke, flaviof to find a document contact vict.... volunteer
15:18:25 <edwarnicke> mestery: Could you #info silence for us again ;)
15:18:34 <regXboi> #topic New items for Be
15:18:42 <regXboi> yea - shiny stuff!
15:18:53 <regXboi> #info L2gateway -
15:19:01 <regXboi> #link https://git.opendaylight.org/gerrit/#/c/24598/ l2GW patch set
15:19:15 <regXboi> I've looked at it and had some nits, but it's a very good first step
15:19:28 <regXboi> great progress, folks :)
15:19:45 <Sangeeta> thanks !
15:19:48 <regXboi> #info regXboi is pleased with what he sees there
15:19:57 <edwarnicke> 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 <armax> edwarnicke: we do
15:20:15 <regXboi> Sangeeta: can you help edwarnicke and #link in the docs?
15:20:25 <regXboi> armax: ^^^^^
15:20:47 <armax> #link https://github.com/openstack/networking-l2gw/blob/master/specs/kilo/l2-gateway-api.rst
15:20:53 <armax> but it may be patchy
15:20:57 <regXboi> #undo
15:20:57 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Link object at 0x1c1ad90>
15:21:07 <regXboi> #link https://github.com/openstack/networking-l2gw/blob/master/specs/kilo/l2-gateway-api.rst l2 gateway neutron API
15:21:28 <regXboi> (sets context in the minutes)
15:21:35 <armax> best is to look at the extensions code
15:21:41 <Sangeeta> i am new to irc din't get actually whats needs
15:21:43 <edwarnicke> armax: LOL
15:21:51 <regXboi> please take a look folks :)
15:22:04 <regXboi> Sangeeta: no worries, just watch and learn as we go :)
15:22:15 <edwarnicke> ijw: What people do gets done.  Sangeeta is doing the work, so its getting done :)
15:22:21 <Sangeeta> :-)
15:22:21 <edwarnicke> Sangeeta: Welcome, happy to have you join us :)
15:22:25 <regXboi> #info Multi OS region proposal from HP
15:22:36 <regXboi> #link https://lists.opendaylight.org/pipermail/neutron-dev/2015-August/000260.html initial email of proposal
15:22:50 <regXboi> looking at this, I'm really thinking this is a separate project
15:23:23 <edwarnicke> regXboi: Can we talk more about that
15:23:29 * edwarnicke pauses to re-review the thread
15:23:31 <ijw> 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 <regXboi> edwarnicke: sure
15:23:53 <regXboi> ijw is correct
15:24:00 <edwarnicke> regXboi: I don't quiet follow how this is a separate project
15:24:03 <edwarnicke> regXboi: Could you say more?
15:24:13 <regXboi> so here's the problem
15:24:26 <regXboi> you are doing something to nit ODL clouds together
15:24:35 <edwarnicke> ODL clouds, or OS clouds?
15:24:43 <ijw> both
15:24:58 <regXboi> well... I'll say ODL clouds, because you aren't doing anything at the OS level
15:25:00 <yapeng> is ODL neutron project scope including interfacing with multiple neutron servers or openstack instances?
15:25:05 <edwarnicke> regXboi: Fair enough :)
15:25:12 <regXboi> yapeng: that is what we are discussing
15:25:14 <edwarnicke> regXboi: You were saying?
15:25:36 <regXboi> my opinion is that the project's scope doesn't include the logic of trying to tie together multiple OS regions
15:25:57 <regXboi> Talking to multiple neutron servers in the same region (i.e. HA) is part of the scope
15:26:18 <ijw> 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 <yapeng> regXboi, agreed.
15:26:35 <regXboi> er part of our scope
15:26:38 <edwarnicke> regXboi: Lets dig into that though
15:26:49 <edwarnicke> regXboi: Because while I agree with the 'nitting together isn't in our scope' part
15:26:55 <edwarnicke> regXboi: I think I'm coming to a different conclusion
15:27:02 <regXboi> edwarnicke: say more
15:27:06 <edwarnicke> My current thinking is this:
15:27:13 <edwarnicke> We don't nit together anything in neutron-northbound anyway
15:27:15 <arieln> The ODL are fedrated. The OS are seprated.
15:27:18 <edwarnicke> The providers do that
15:27:42 <ijw> 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 <edwarnicke> 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 <edwarnicke> stitching together is their problem
15:28:08 <edwarnicke> regXboi: Does that make sense?
15:28:24 <regXboi> edwarnicke: up until the "so ..." statement, I'm on board
15:28:31 <regXboi> but my reaction is the exact opposite
15:28:38 <edwarnicke> 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 <ijw> 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 <ijw> 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 <edwarnicke> ijw: I can see the use case for why you would want to do what is being suggested though
15:29:28 <edwarnicke> ijw: Amen to that
15:29:37 <regXboi> 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 <regXboi> because since the two OS regions *are* truly independent, we have to take some protective steps
15:30:18 <ijw> 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 <edwarnicke> 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 <edwarnicke> regXboi: Say more about the non-transparency... because I don't see it yet
15:30:39 <armax> apologies if I sounds as clueless as usual
15:30:42 <armax> but do we have more context behind the email proposal?
15:31:01 <edwarnicke> armax: What kind of more context are you interested in? :)
15:31:26 <armax> 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 <regXboi> folks - I'm going to budge 15 more minutes for this, because we have other things to get to
15:31:41 <regXboi> er budget, not budge
15:31:50 <mestery> budge works too
15:31:56 <regXboi> I encourage the discussion, but we have other proposals to consider
15:32:15 <armax> but a Neutron network can be a provider network, a tenenat network, an external network
15:32:19 <edwarnicke> 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 <ijw> https://lists.opendaylight.org/pipermail/neutron-dev/2015-August/000262.html is more context
15:32:30 <armax> they have IP spaces associated to them
15:32:35 <armax> and other properties
15:32:43 <arieln> Need to be two seperated ODL clusters as it need to support two diffrenet data-center multi sites
15:32:43 <ijw> Which makes clear that the point we are discussing is not the point the author was making
15:33:01 <regXboi> #link https://lists.opendaylight.org/pipermail/neutron-dev/2015-August/000262.html provides more context to this request
15:33:08 <regXboi> #info lots of discussion - see the logs for details
15:33:12 <armax> ijw: thanks
15:33:24 <edwarnicke> 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 <armax> 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 <armax> L3
15:34:07 <regXboi> edwarnicke, ijw: the context email actually makes my case for this being a separate project
15:34:12 <edwarnicke> armax: I suspect they want to use tunnels for overlays...
15:34:18 <edwarnicke> regXboi: Looking
15:34:19 <regXboi> because it's two ODLs, two OSs, two ....
15:34:27 <ijw> regXboi: it changes the NBI but it equally changes a lot of other things
15:34:28 <regXboi> and yes, they want VxLAN
15:34:54 <edwarnicke> arieln: Are you Ariel from the thread?
15:34:55 <armax> but the IP’s spaces must be carefully crafted
15:35:03 <arieln> yes
15:35:09 <edwarnicke> armax: Yes, and don't get me started on the mac space ;)
15:35:16 <edwarnicke> arieln: Excellent :)
15:35:21 * ijw finds edwarnicke's dried frog pills
15:35:22 <armax> edwarnicke: well that too
15:35:27 <edwarnicke> arieln: Could you help us understand some of these questions?
15:35:47 * edwarnicke has finally completely missed ijw's reference
15:35:48 <armax> so, for instance, do we intend to expose this all the way to tenants?
15:36:02 <armax> or we restrict this to provider networks only?
15:36:17 <edwarnicke> I like to think of things in simple steps
15:36:18 <armax> where things may be slightly more controlled?
15:36:24 <arieln> I do ot think it change the openstack API as of today it beyhond a single OS
15:36:27 <regXboi> armax: the way I read the proposal is that horizon, et.al. are unaware of all of this
15:36:39 <arieln> Can be ODL API
15:36:41 <regXboi> arieln: uh, what?
15:36:57 <edwarnicke> 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 <ijw> 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 <edwarnicke> But when it comes to the stitching
15:37:14 <edwarnicke> That's complicated
15:37:57 <edwarnicke> arieln: I think I'm getting a better picture in my head of what you are asking for
15:37:59 <arieln> Agreee with ijw
15:38:21 <edwarnicke> 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 <regXboi> I've yet to be convinced this is anywhere close to in scope
15:38:50 <regXboi> in fact, the more this discussion goes on, the less convinced I become
15:39:06 <ijw> 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 <arieln> You need to map the names to a third entity in the mapping in each OS.
15:39:14 <armax> regXboi: I hope that wasn’t my fault
15:39:21 <edwarnicke> arieln: How?
15:39:23 <armax> regXboi: but I don’y mind you think it is
15:39:24 <regXboi> armax: no... ijw nailed it
15:39:32 <armax> ijw rocks
15:39:35 <arieln> MAkeing sure MAC are in the space of OS config
15:39:45 <arieln> same as L2network
15:39:48 <regXboi> armax: because this can't be solved by code here and nowhere else, this is outside our scope
15:39:51 <ijw> 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 <ijw> Honestly openstack-dev is not a bad place
15:40:17 <armax> regXboi: well, true, this is not just a Neutron Northbound project alone
15:40:26 <regXboi> ijw: +1 with a modification
15:40:35 <edwarnicke> 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 <edwarnicke> you don't have to reinvent the wheel :)
15:40:59 <regXboi> 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 <ijw> 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 <edwarnicke> regXboi: As long as we keep the existing thread context on the ODL side, I'm down
15:41:20 <yapeng> ijw: +1
15:41:42 <edwarnicke> arieln: How do you feel about this, does it feel like its moving in a productive direction to you?
15:42:04 <arieln> We can take it offline and go over the point raise
15:42:36 <ijw> 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 <arieln> ok thanks
15:43:06 <edwarnicke> regXboi: Next up?
15:43:11 <regXboi> #info Should networking-ODL be re-written? should it become a monolithic plugin? where should it live?
15:43:42 <regXboi> my answers are yes, don't care, and don't care (so long as my concerns are addressed :) )
15:43:54 <regXboi> yes I think it should be rewritten
15:43:59 <armax> I am sure ijw  would add ‘should neutron northbound be re-written too’, no?
15:44:13 <regXboi> armax: that's for later
15:44:17 <armax> ah
15:44:18 <flaviof> #link http://sched.co/3yTL Experiences using ODL with Neutron/OpenStack - Wojciech Dec
15:44:23 <armax> sorry I jumped the gun
15:44:25 <flaviof> I asked Wojciech to make slides available, but I am not sure if that has happened.
15:44:50 <ijw> 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 <flaviof> 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 <flaviof> bugzilla/launchpad.
15:44:58 <yamahata> ML2 is working on task-flow to address status synching. Can we leverledge that?
15:45:08 <flaviof> Net to net conclusion was that networking-odl needs to be looked as an integral piece of the neutron northbound project.
15:45:27 <yamahata> I suppose they are seeing similar issues
15:45:33 <edwarnicke> flaviof: I see the slides as a PDF there
15:45:38 <ijw> 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 <mestery> We should rewrite as a core plugin
15:45:41 <agupta> https://wiki.opendaylight.org/view/NeutronNorthbound:2015Summit#Material_from_July_2015_ODL_Summit
15:45:43 <mestery> Not an ML2 driver
15:45:45 <flaviof> edwarnicke: got link?
15:45:52 <regXboi> well... I agree that it should be rewritten
15:45:55 <mestery> Why do we need the abstraction ML2 provides? Doesn't ODL want to own the world here?
15:45:55 <mestery> Meh
15:46:05 <regXboi> but I think the folks that *do the work* get to choose how it should be rewritten :)
15:46:14 <flaviof> i hear from folks like mlemay on this
15:46:16 <edwarnicke> I think agupta beat me to it :)
15:46:21 <edwarnicke> Guys
15:46:23 <edwarnicke> Lets break this down
15:46:27 <flaviof> edwarnicke: agupta: ty
15:46:31 <edwarnicke> Because I think we have three discussion here
15:46:45 <edwarnicke> 1)  Should odl-neutron transition from being an ML2 driver to a full plugin
15:46:46 <mlemay> Ahh I got named !
15:46:50 <mlemay> ;)
15:46:55 <armax> as for 1
15:46:56 <flaviof> #link https://wiki.opendaylight.org/view/NeutronNorthbound:2015Summit#Material_from_July_2015_ODL_Summit Experiences with Neutron & ODL Slides
15:46:57 <regXboi> #link https://wiki.opendaylight.org/view/NeutronNorthbound:2015Summit#Material_from_July_2015_ODL_Summit slides in background of this discussion
15:47:02 <edwarnicke> 2)  Where should odl-neutron live?  Do we want to migrate it to neutron-northbound at ODL
15:47:03 <regXboi> um edwarnicke, that isn't #1
15:47:13 <edwarnicke> 3)  Stuff we have to do to fix HA/scalability
15:47:27 <mestery> edwarnicke: If you never want it tested, then definitely yes for #2
15:47:28 <edwarnicke> My sense is that #1 and #2 are simpler discussions, and so my bias is to figure those out first :)
15:47:42 <regXboi> so, if you look at the agenda
15:47:44 <edwarnicke> mestery: Could you say more? :)
15:47:50 <regXboi> #3 is a separate topic
15:47:52 <mlemay> Hey Kyle how is it going?
15:47:55 <mestery> edwarnicke: Yes: The CI for ODL has never worked with OpenStack
15:47:57 <mestery> flaviof: ^^^
15:47:58 <regXboi> so it's off the table right now
15:48:02 <ijw> OK, so let's start with #1
15:48:03 <mestery> And no one has ever helped us fix it
15:48:05 <mestery> Other than flaviof and I
15:48:13 * regXboi glares at mestery
15:48:14 <edwarnicke> mestery: I hear you
15:48:15 <mestery> By keeping the driver on the OpenStack side
15:48:18 <mestery> We get CI for free
15:48:25 <mestery> Makes no sense to move it to ODL
15:48:25 <mestery> BUT
15:48:33 <ijw> OK, let's start with #2...
15:48:35 <mestery> Yes
15:48:37 <mlemay> 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 <edwarnicke> mestery: Is that CI working though?  My sense is that its had a lot of challenges
15:48:41 <armax> the bigger question for 1) is: what does moving away from ml2 buy us, and what do we lose?
15:48:41 <mestery> ijw: Yes
15:48:53 <mestery> edwarnicke: If you want challenges, try getting it working on the ODL side
15:49:03 <ijw> So can I suggest it's not about where the source lives, particularly, the problem is who's responsible for it
15:49:04 <regXboi> ok folks.... I'm going wrap my shoe on the table here
15:49:05 <mestery> All the challenges are due to things unrelated to the infra
15:49:10 <regXboi> let's back up a minute
15:49:13 <mestery> Moving it to ODL would introduce an entirelly new set of challenges
15:49:14 <regXboi> we jumped to #2 :)
15:49:14 <armax> to be the biggest loss is the easy of migration from agent-based to controller-based architecture
15:49:17 <ijw> I would suggest that we combine the teams for maintaining it and the NB part of ODL
15:49:20 <edwarnicke> 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 <mestery> Bah
15:49:33 <mestery> It's pointless to even consider moving it IMHO
15:49:42 <flaviof> 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 <edwarnicke> I think regXboi is wise to try to walk through these in order... because I think #1 is easier than #2 ;)
15:49:55 <mestery> edwarnicke: Wrong
15:49:55 <mestery> #2 is easier
15:49:56 <armax> #2 I am not usre I even understand what it means
15:50:01 <mestery> It's pointless to move it. Any questions?
15:50:14 <edwarnicke> Guys... lets start with #1
15:50:17 <mestery> There is actually less than zero benefit to moving it
15:50:22 <regXboi> mestery: it is one of these "who is going to do the work things...."
15:50:40 <mestery> regXboi: No, it's not. It makes no sense to move it out at all.
15:50:44 <regXboi> at least my opinion on *BOTH* #1 and #2 is it is a "who is going to do the work things...."
15:50:49 <mestery> Someone needs to tell me *what benefit* there would be to moving it.
15:50:54 <ijw> regXboi: then arguably we're offering advice to whoever picks up the baton
15:51:03 <regXboi> ijw: bingo
15:51:20 <edwarnicke> Guys.. could we talk about the ML2 to plugin (#1) as it (hopefully) is less charged :)
15:51:34 <ijw> 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 <armax> but does the move imply a more fundamental change in the code, programming language etc?
15:51:38 <armax> it’s unclear to me
15:51:41 <regXboi> 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 <edwarnicke> 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 <regXboi> 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 <mestery> 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 <regXboi> and so somebody has to *guarantee* that CI will work and that they will handle care and feeding of it
15:52:35 <mestery> edwarnicke: For one, I expect that one will fall out of who does the work.
15:52:41 <flaviof> i think we have to stop looking at networking-odl and nn as 2 projects
15:52:46 <ijw> 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 <ijw> Where it lives is entirely secondary
15:52:53 <edwarnicke> flaviof: Also a good point
15:53:07 <regXboi> flaviof: today, the are separate projects
15:53:08 <ijw> flaviof++, the point I was making in 10 words
15:53:33 <flaviof> regXboi: they look like they are... but one is meaningless w/out the other
15:53:58 <flaviof> it just happens that 1/2 lives in neutron as a plugin as the other is part of odl.
15:54:09 <ijw> regXboi: in the future they'll probably also be separate projects too - but the *people* should be the same
15:54:12 <edwarnicke> 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 <edwarnicke> position on the rightness and wrongness of that sense)
15:54:17 <regXboi> flaviof: that's *not* entirely true
15:54:34 <armax> I don’t understand how the move would work
15:54:35 <flaviof> regXboi: how so? is nn of any value w/out neutron?
15:54:46 <armax> if one would be kind enough to elaborate what it means
15:54:49 <ijw> 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 <armax> today Neutron needs a core_plugin set to work
15:54:56 <regXboi> historically, there have been other ODL plugins that talked to NN
15:54:58 <edwarnicke> 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 <ijw> You can't upgrade ODL and Openstack in the same instant
15:55:05 <armax> and if that’s ml2, it needs a mech_driver to work
15:55:08 <regXboi> only historically, mind you
15:55:18 <armax> edwarnicke: I feel great
15:55:20 <regXboi> er wait - I said that wrong - OS
15:55:32 <armax> but I sense I am not useful to this discussion if I don’t understand the premise
15:55:36 <armax> and the assumptions
15:55:37 <edwarnicke> armax: Are you commenting on #1 (the ML2 driver vs plugin) discussion?
15:55:45 <mestery> armax: lol
15:55:56 <edwarnicke> armax: As I said, part of this discussion is fleshing all of that out ;)
15:55:59 <armax> you guys go from #1 to #2 and back like hummingbirds
15:56:08 <armax> I am not so fast
15:56:08 <flaviof> lol
15:56:11 <edwarnicke> armax: Good point
15:56:12 <edwarnicke> Guys
15:56:16 <edwarnicke> Could we focus on #1 for a while
15:56:18 * ijw craps on armax's head
15:56:25 <mlemay> Yea would be better to go at it item by item
15:56:25 * mestery gives up
15:56:27 <armax> I learned to read only a week ago
15:56:31 <ijw> OK, #1: why is it a good idea to move?
15:56:44 <regXboi> um... #1 isn't about moving
15:56:49 <edwarnicke> ijw: No, #1 is Ml2 -> plugin
15:56:50 <flaviof> ijw: what does 'move' mean?
15:56:56 <armax> regXboi: it’s a separate move
15:56:57 <flaviof> ah... ok
15:57:21 <ijw> edwarnicke: yes, I am aware of that - why is a good idea to move to being a plugin?
15:57:33 <armax> as for #1 I think that both places for the ODL integration have pros and cons
15:57:36 <regXboi> folks, I really don't have any skin in the discussion ... I want to know "who is volunteering to do it"
15:57:44 <ijw> armax: list three
15:58:00 <armax> three of what?
15:58:02 <ijw> regXboi: why volunteer to do it if you can't see the reason for doing it?
15:58:08 <ijw> armax: pros and cons
15:58:28 <regXboi> ijw: if I there isn't someone to write the code, then the discussion is empty
15:58:28 <flaviof> right, on #1: i would like to hear more on whay that is neeed; for sake of completeness
15:58:40 <armax> the biggest con I see to be part of ml2 is that we carry a baggage we might not want
15:58:52 <armax> but that baggage at the same time is flexibility we may want
15:59:08 <edwarnicke> armax: Can you say more about the flexibility?
15:59:18 <edwarnicke> armax: What flexibility is it buying us?
15:59:26 <flaviof> armax: the issues with sync/etc.. are they pertinent to ml2?
15:59:32 <armax> flaviof: no?
15:59:36 <ijw> flaviof: nope
15:59:52 <flaviof> ack. my reason to ask is that I see a bit of confusion on
16:00:01 <ijw> flaviof: ml2's mech driver structure helps highlight them but they'd be there regardless
16:00:05 <flaviof> known issues and why / what that is related to mls.
16:00:11 <armax> edwarnicke: the flexibility is given by the fact that we can run multiple l2 technologies at the same time
16:00:21 <flaviof> ml2. it makes ml2 a 'bad' think when in fact it has nothing to do with that.
16:00:22 <edwarnicke> armax: OK, is there any other flexibility?
16:00:38 <armax> edwarnicke: so for instance we can have built-in openvswitch and odl running smoothly side by side
16:00:48 <armax> today the Neutron world is agent-based
16:00:58 <mestery> armax: Who in their right mind would do that?
16:01:00 <ijw> 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 <mestery> armax: Has anyone ever done that?
16:01:01 <regXboi> armax: let me put on my operator hat
16:01:10 <mlemay> ok I can type now.. sorry guys
16:01:12 <armax> so if people think that customers are gonna ditch their existing enviroment to embrace something that ODL has yet to deliver seems ludicrous
16:01:18 <flaviof> trouble is ml2 is not enough, especially because odl needs l3, lbass, etc...
16:01:24 <regXboi> NO OPERATOR IS GOING TO RUN A HETEROGENEOUS NETWORK
16:01:33 <regXboi> not if they are sane, that is
16:01:34 <armax> regXboi: not at the same time and for ever
16:01:41 <armax> regXboi: I am thinking about the migration
16:01:44 <armax> from one to the other
16:01:50 <armax> regXboi: there’s no need to be rude anyway
16:01:50 <regXboi> armax: that's a really *thin* point
16:01:58 <armax> I am kindly making a point
16:02:00 <edwarnicke> paging dneary who has been thinking a lot about transition...
16:02:00 <mestery> armax: Do you seriously think we can migrate people from ML2+OVS to ODL?
16:02:01 <armax> regXboi: ok
16:02:10 <edwarnicke> armax: Many thanks for making that point :)
16:02:11 <mestery> That's a pipe dream
16:02:14 <mlemay> armax: indeed no one wants to run multiple ml2 drivers when they decide to take the hit and bring in a controller to the picture
16:02:14 <regXboi> armax: not meaning to be rude, but trying to get people's attention
16:02:15 <flaviof> #link https://www.dropbox.com/s/25w3dydlbp885tn/Screenshot%202015-08-07%2012.02.04.png?dl=0 neutron archit
16:02:18 <armax> ok
16:02:19 <armax> that’s fine
16:02:22 <armax> let’s move on
16:02:30 <armax> 2 minutes past the hour
16:02:35 <armax> I love you guys
16:02:40 <armax> but I need to go
16:02:42 * armax takes off
16:02:42 <regXboi> folks - we really need to take this all to the ML
16:02:45 * mestery takes the kool aid away from armax
16:02:46 <regXboi> bye, armax
16:02:46 <edwarnicke> armax: How are other folks handling that transition?  In browsing through the github tree it still looks like most folks are doing plugins
16:02:49 <mlemay> armax: okidoo cheer buddy
16:02:52 <ijw> yup
16:02:58 <flaviof> armax: thanks!
16:03:09 <edwarnicke> mestery: Are you really going to be the one who takes away the punch bowl? ;)
16:03:10 <ijw> So I would consider this three *independent* points, so beware taking it to the ML as a lump
16:03:23 <edwarnicke> ijw: Good advice
16:03:25 <regXboi> ijw: agreed, these need to be separate discussions
16:03:34 <edwarnicke> We saw what happens when we bring them as one piece right here ;)
16:03:40 <ijw> I think we've just demonstrated what happens if we do that
16:03:43 <edwarnicke> regXboi: Would you kick off the threads?
16:04:01 <regXboi> #action regXboi to kick off threads on networking-ODL
16:04:03 <regXboi> sigh
16:04:08 <mestery> lol
16:04:11 <flaviof> my point in the link above is to point out ml2 is not enough to achieve the co-existence that makes it attarctive
16:04:13 * edwarnicke hugs regXboi
16:04:33 <edwarnicke> flaviof: Please say more
16:04:36 <dneary> edwarnicke, Sorry - distracted
16:04:50 <flaviof> edwarnicke: if you look at https://www.dropbox.com/s/25w3dydlbp885tn/Screenshot%202015-08-07%2012.02.04.png?dl=0
16:05:05 <flaviof> edwarnicke: ml2 is just well... l2.
16:05:08 <edwarnicke> dneary: We were discussing the possibility of the rewriting the neutron ML2 driver as a neutron plugin
16:05:12 <dneary> edwarnicke, mestery, armax: I would like to try it and see... was installing a little cluster here
16:05:22 <edwarnicke> The point of what that would do to transition was raised by armax
16:05:34 <edwarnicke> I paged you because I think you are the holder of the deep thought on customer transitions here
16:05:38 <edwarnicke> So I wanted your opinion
16:05:41 <flaviof> edwarnicke: for l3, lbaas, etc, there is still no way of having multiple plugins
16:05:43 <ijw> flaviof: One of the points of ml2 (argue the benefit if you will) is that you don't have to bring L2 and L3 and every aaS offering from the same controller
16:05:46 <ijw> I think that stands here
16:05:54 <edwarnicke> flaviof: Excellent point
16:06:15 <ijw> ml3 is being debated, as are service flavours
16:06:22 <viveknarasimhan> flaviof: Tend to agree to have a separate Plugin
16:06:31 <ijw> But perhaps the point is that you could at least choose to use ODL for what it does and an indeepndent aaS for what it doesn't
16:06:43 <edwarnicke> viveknarasimhan: Thank you for speaking up: more voices (either way) is better :)  Can you say more about why you feel that way?
16:06:50 <ijw> Which would be difficult if ODL was the *only* way to get things done
16:07:13 <viveknarasimhan> flaviof: Would give flexibility for ODL to handle neutron APIs the way it best fits an ODL implementation which is purely controller-driven
16:07:39 <ijw> Bear in mind for LBaaS you're now basically saying that a vendor would have to write one plugin in Neutorn for the ML2 users and one in ODL for the ODL users
16:07:48 <edwarnicke> ijw: Out of curiousity, how would that work on the ground, as I suspect either the independent *aaS thingie would have to get its hands in flow tables ODL is managing it doesn't understand, or otherwise muck with where the traffic is going... or am I missing something
16:08:39 <ijw> edwarnicke: given the way they work and *providing* they're nice and independent they don't have to do fabric tweaks, they just need an attachment point - but I grant that it's more optimism than reality in a lot of cases - VPNaaS is hard to separate from routing, for instance
16:09:18 <ijw> edwarnicke: I agree there's some distance between the dream and the reality
16:09:24 <edwarnicke> ijw: I am having a hard time thinking of a *aaS that could be easily separated... do you have an example?
16:09:29 <ijw> LBaaS
16:09:36 <ijw> Is actually a pretty good one
16:09:49 <edwarnicke> Any others?
16:09:51 <ijw> Router as a service too, actually
16:10:02 <ijw> (i.e. L3)
16:10:11 <ijw> Whether you *would* separate them is another question
16:10:13 <regXboi> um...
16:10:15 <edwarnicke> Sure... but only if you are chosing not to use the existing ODL L3 services
16:10:21 <regXboi> #topic discussion rather than cookies
16:10:24 <regXboi> #endmeeting