17:01:24 <Sukhdev> #startmeeting networking_l2gw
17:01:25 <openstack> Meeting started Mon Sep 14 17:01:24 2015 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:28 <openstack> The meeting name has been set to 'networking_l2gw'
17:01:38 <Sukhdev> hi vikas
17:02:04 <Sukhdev> mondays are crazy for me - back-to-back meetings :-)
17:02:28 <vikas> :-)
17:02:28 <Sukhdev> who else is here? please give me a shout
17:02:36 <Sukhdev> armax: are you here?
17:02:50 <armax> maybe
17:03:28 <Sukhdev> armax: ah ha - I was looking for you in neuron channel -
17:03:43 <Sukhdev> armax: we need you here - as I have couple of items where we need you
17:03:55 <armax> k
17:04:12 <Sukhdev> looking maruti is not here yet
17:04:26 <Sukhdev> #topic: Agenda
17:04:37 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/L2Gateway
17:04:52 <Sukhdev> #topic: Announcements
17:05:15 <Sukhdev> Liberty is around the corner - RC1 is in the works
17:05:30 <Sukhdev> Later we will discuss when do we want to release?
17:05:58 <Sukhdev> Anybody has any announcements?
17:06:22 <gsagie_> I have a general question, is L2GW aimed at solving spanning networks across clouds (public+private) ?
17:06:31 <gsagie_> or is that not an "official" mission
17:07:05 <Sukhdev> gsagie_: thanks and welcome to our meeting
17:08:08 <Sukhdev> gsagie_: I am sure armax will chime in - but, the charter of L2 GW is to provide inter-connect between two L2 broadcast domains
17:08:24 <Sukhdev> to create a one larger L2 broadcast domain
17:08:35 <armax> gsagie_: are you thinking of spanning an l2 broadcast domain over WAN?
17:08:44 <Sukhdev> gsagie_: so, based upon that definition, yes - it covers your use case
17:08:46 <gsagie_> armax: yes
17:09:20 <Sukhdev> gsagie_: so couple of things
17:09:20 <armax> gsagie_: I am sure there are use cases
17:09:31 <armax> gsagie_: I would never use it if it was available though
17:09:35 <armax> performance would suck
17:10:40 <Sukhdev> gsagie_: the two things that I was going to mention is - 1)
17:11:03 <Sukhdev> 1) present implementation is based upon OVSDB -
17:11:04 <armax> can’t say that latency would be enough to dismiss it entirely
17:11:36 <Sukhdev> 2) the orchestration -
17:12:19 <gsagie_> armax: there are some use cases for that in the telco world, but it really depends how you use it and how you implement it, i am not sure actually sending ARP's across WAN make sense but was asking from an API level
17:12:31 <Sukhdev> armax: you mean performance because of encap/decap on both ends?
17:13:38 <Sukhdev> gsagie_: my point 2) was going to cover the API level orchestration
17:13:41 <armax> Sukhdev: not just that alone
17:14:23 <armax> gsagie_: I think that there’s more to understand before we can model it through the api
17:15:27 <armax> we are really crossing the vpn site-to-site use case too
17:15:31 <armax> to some extent
17:16:06 <gsagie_> armax: i agree, i was looking at the current API and think it needs more work for that use case, but didn't want to jump in with it and spend all your time without understanding if thats a project goal
17:18:00 <armax> we’d have to understand more about your use case
17:18:17 <armax> without further details it’s diffucult to assess that it can be a project goal
17:18:24 <armax> in lack of further input I’d say, no
17:18:25 <Sukhdev> gsagie_: even though we have specifically have not said that we will use L2GW for that purpose, but, your use case definitely falls into the broader category
17:18:56 <armax> for instance, are you thinking of bridging another l2 neutron doamin with another neutron one?
17:19:06 <armax> are you thinking of VM to VM traffic?
17:21:07 <armax> we can surely discuss, but it seems premature to expand the project further when the basics are still missing
17:21:14 <gsagie_> One of the use cases is to have a neutron network span across 2 clouds, so you could have VM's deployed in both clouds and all in the same L2 network,
17:21:35 <gsagie_> armax: ok, maybe i will consult with some people and propose a document that describe the use cases
17:22:03 <armax> gsagie_: two separate neutron deployments?
17:22:12 <gsagie_> armax: yes
17:22:26 <armax> gsagie_: have you thought on how you’re gonna handle ipam?
17:22:32 <Sukhdev> thinking in a very simplistic way, one could create an L2 GW on one l2 neutron domain to map VxLAN to a VLAN and create another one in the other neutron domain and use the same VLAN
17:22:53 <Sukhdev> to create connectivity - hence, understanding the orchestration is important
17:23:58 <Sukhdev> gsagie_: I think documenting the use case will really help -
17:24:22 <gsagie_> armax: yes, in our case we have a centralised control plan that does the allocating
17:24:44 <armax> gsagie_: so it’s not two separate neutron deployments then?
17:25:27 <armax> if they share ipam
17:25:29 <armax> I mean
17:26:26 <gsagie_> armax : its two deployment that are controlled from a centralised location, i guess they are not "separate"
17:27:12 <armax> gsagie_: I am sorry, I am not sure what this means
17:29:03 <gsagie_> armax: We have a project (Tricircle) in stack forge, it takes a centralised OpenStack layer and it controls other OpenStack clouds, it has its own implementation (for nova for neutron and so on) that what it does in a nutshell is split the OpenStack API calls and sync the resources between the different clouds
17:29:06 <Sukhdev> gsagie_: I think this complicates - if you keep two separate deployments and use L2 GW on both sides to bridge on the same VLANs, then I could see it working - otherwise, I am at loss as well :-):-)
17:30:19 <gsagie_> and we use availability zone to mark the specific cloud, so the user can using OpenStack API (or UI) to deploy VM's in different clouds by picking different availability zone
17:30:38 <gsagie_> and the project layer, knows to sync all the dependent resources
17:31:13 <gsagie_> armax: https://wiki.openstack.org/wiki/Tricircle
17:31:16 <gsagie_> more information
17:31:17 <armax> gsagie_: sounds like a lot of complication
17:32:00 <Sukhdev> gsagie_: Interesting - this gives me something to read about -
17:32:43 <armax> you could bridge the clouds completely transparently without ever letting the admin know about it
17:32:48 <Sukhdev> gsagie_: coming back to L2GW, I think, if you can document as to how do you envision using it, then we can discuss further and provide guidance
17:33:53 <gsagie_> Sukhdev: ok thanks, i will do that, we have some ideas API/implementation wise
17:34:03 <Sukhdev> armax: that is what I was thinking in my earlier statement - but, it will be good to understand the deployment model better
17:34:14 <armax> Sukhdev: yes
17:35:24 <Sukhdev> #action: gsagie_ to document inter-cloud connectivity use case
17:35:32 <Sukhdev> Folks, I want to return back to the agenda - as we have couple of critical items to discuss
17:35:34 <gsagie_> armax: the tenant has the option to deploy the VM's in which ever cloud he/she wants (or allowed), and of course i guess the pricing/performance model changes accordingly so i am not sure what do you mean "bridge the clouds completely transparently" ?
17:36:15 <gsagie_> ok, sorry for taking too much time
17:36:24 <gsagie_> will document it and post the link, thanks for the time
17:36:33 <Sukhdev> gsagie_: when you write it up, I can help you clarify as to how this will all play out
17:37:27 <Sukhdev> gsagie_: lets discuss the details after you have your thoughts on the document
17:37:39 * Sukhdev returning back to the agenda now
17:37:41 <gsagie_> Sukhdev: ok, thanks
17:37:54 <Sukhdev> #topic: L2GW release planning for Liberty
17:38:42 <Sukhdev> armax: we are close in terms of our work for L2 GW - barring some pending patches (next agenda item)
17:39:30 <Sukhdev> armax vikas: Can you think of things that we need to do before the release?
17:40:06 * Sukhdev waiting
17:40:36 <armax> Sukhdev: what things?
17:41:02 <Sukhdev> any logistical issues - other than merging pending patches
17:41:36 <armax> k
17:41:53 <Sukhdev> armax: by logistics - I mean any release announcement - adding this to neutron Liberty release notes, documentation for neutron etc....
17:43:11 <Sukhdev> armax: any thoughts?
17:43:30 <armax> none
17:44:23 <Sukhdev> armax: if you think of any, which we need to prepare, please let me know (ping me)
17:44:56 <armax> will do
17:45:43 <Sukhdev> armax: https://review.openstack.org/#/c/202495/
17:46:09 <Sukhdev> armax: you have -2 on this - have you had a chance to look into the issue?
17:46:22 <Sukhdev> We have tested this and it looks ready to go -
17:46:57 <armax> Sukhdev: ok let me double check with henry
17:47:00 <armax> and I’ll get it sorted
17:47:35 <Sukhdev> armax: OK - thanks - and, if all checks out OK, please approve it for merge
17:47:42 <armax> will do
17:48:06 <Sukhdev> armax: we have couple of back port patches for killo that require core approval -
17:48:33 <Sukhdev> armax: I am assuming this is from the infra core people, right?
17:48:55 <Sukhdev> armax: shall I go bug them on infra channel - or my understanding is wrong?
17:48:56 <armax> Sukhdev: no the stable team
17:49:02 <armax> so kyle, et al
17:49:05 <Sukhdev> armax: who is that?
17:49:12 <Sukhdev> kyle already approved it?
17:49:23 <armax> ihar or gary would be the others
17:49:23 <Sukhdev> so, it is you and doug then
17:49:59 <Sukhdev> armax: OK - I will make noise on neutron channel then -
17:50:27 <Sukhdev> armax: next one this - https://review.openstack.org/#/c/221932/
17:50:51 <Sukhdev> do we want to approve it? I think this has to do with python 3, right?
17:51:11 <Sukhdev> I am not too sure about it
17:52:13 <Sukhdev> vikas: BTW, I have asked ash win to test this - https://review.openstack.org/#/c/222841/
17:52:34 <Sukhdev> vikas: will let you know as soon we are done with the testing - or will approve it
17:52:40 <vikas> ok fine
17:53:09 <Sukhdev> armax: any thoughts on that patch? python 3 scares me - :-)
17:53:23 <Sukhdev> armax: or I am reading too much into this?
17:53:43 <armax> not sure I have teh full context
17:55:22 <Sukhdev> armax: this patch came from some infra - even I do not have context -
17:55:41 <Sukhdev> armax: since you are more plugged in, I thought you would know :-)
17:56:16 <armax> which one?
17:56:25 <armax> the bot patch?
17:56:27 <armax> that’s fine
17:56:31 <Sukhdev> yes
17:56:55 <Sukhdev> what is that for?
17:56:56 <armax> that’s a version bump that kyle posted a few days ago
17:57:06 <armax> he released a new version of the client
17:57:38 <Sukhdev> armax: Oh - I thought this has to do with python 3.0 support -
17:57:47 <armax> nop
17:57:50 <Sukhdev> armax: oh no worries then
17:58:02 <Sukhdev> armax: shall we approve it for merge then?
17:58:15 <armax> go ahead
17:58:33 <Sukhdev> armax: cool -
17:58:45 <Sukhdev> #topic: Mitaka discussion
17:59:30 <Sukhdev> armax: we do not have full quorum here - but, any thoughts about Mitaka for L2 GW?
17:59:59 <armax> not sure what’s the point of talking about mitaka
18:00:04 <armax> when nothing got done in Liberty
18:00:30 <Sukhdev> armax: I mean the charter for L2GW for mitaka
18:01:07 <Sukhdev> armax: i.e. do we want to plan any new features, use cases for L2GW for mitaka?
18:01:36 <gsagie_> :)
18:01:47 <armax> I think we lack the basics
18:01:57 <armax> and we didn’t tackle those in liberty
18:02:11 <armax> so really Mitaka should be a Liberty redux
18:02:25 <Sukhdev> armax: we got couple of critical enhancements done in Liberty
18:02:45 <armax> meh, that shouldn’t have taken the entire cycle, come on!
18:03:30 <Sukhdev> armax: understood - but, that also depends upon the resource availablity
18:03:37 <armax> we’re over time
18:03:47 <armax> agreed
18:03:52 <Sukhdev> armax: thanks for pointing it out -
18:04:01 <armax> so no resource availability no point on discussing mitaka thoughts
18:04:03 <Sukhdev> we are done - need to free up the channel
18:04:09 <Sukhdev> thanks folks for attending
18:04:17 <Sukhdev> bye
18:04:22 <Sukhdev> #endmeeting