Thursday, 2014-10-09

*** dboik has joined #openstack-meeting-300:01
*** rockyg has quit IRC00:02
*** dboik has quit IRC00:05
*** yamahata has joined #openstack-meeting-300:10
*** cjellick has quit IRC00:14
*** otherwiseguy has quit IRC00:19
*** terryw has joined #openstack-meeting-300:19
*** cjellick has joined #openstack-meeting-300:19
*** openstackstatus has quit IRC00:23
*** ivar-lazzaro has quit IRC00:23
*** openstackstatus has joined #openstack-meeting-300:24
*** ChanServ sets mode: +v openstackstatus00:24
*** cjellick has quit IRC00:24
*** mfer has joined #openstack-meeting-300:27
*** arosen has quit IRC00:28
*** dboik has joined #openstack-meeting-300:36
*** shwetaap has joined #openstack-meeting-300:38
*** mfer has quit IRC00:42
*** markmcclain has quit IRC00:43
*** terryw has quit IRC00:44
*** bpokorny_ has quit IRC00:44
*** otherwiseguy has joined #openstack-meeting-300:45
*** markmcclain has joined #openstack-meeting-300:53
*** terryw has joined #openstack-meeting-300:54
*** otherwiseguy has quit IRC00:54
*** salv-orlando has quit IRC00:55
*** jacalcat has joined #openstack-meeting-301:06
*** s3wong has quit IRC01:07
*** jacalcat has left #openstack-meeting-301:11
*** alexsyip has quit IRC01:13
*** shwetaap has quit IRC01:29
*** stanzgy has joined #openstack-meeting-301:31
*** otherwiseguy has joined #openstack-meeting-301:38
*** terryw has quit IRC01:38
*** jacalcat has joined #openstack-meeting-301:40
*** jacalcat has left #openstack-meeting-301:46
*** shwetaap has joined #openstack-meeting-301:47
*** otherwiseguy has quit IRC01:49
*** otherwiseguy has joined #openstack-meeting-301:49
*** david-lyle has joined #openstack-meeting-301:50
*** markmcclain has quit IRC01:55
*** Longgeek has joined #openstack-meeting-302:26
*** julim has quit IRC02:27
*** lhcheng has quit IRC02:28
*** lhcheng has joined #openstack-meeting-302:28
*** lhcheng has quit IRC02:34
*** hurgleburgler has joined #openstack-meeting-302:41
*** coolsvap|afk is now known as coolsvap02:55
*** armax has quit IRC03:03
*** carl_baldwin has joined #openstack-meeting-303:05
*** armax has joined #openstack-meeting-303:07
*** jacalcat has joined #openstack-meeting-303:08
*** jacalcat has left #openstack-meeting-303:13
*** carl_baldwin has quit IRC03:19
*** chuckC_ has joined #openstack-meeting-303:27
*** coolsvap is now known as coolsvap|afk03:37
*** coolsvap|afk is now known as coolsvap03:45
*** shwetaap has quit IRC03:51
*** hurgleburgler has quit IRC03:53
*** armax has quit IRC03:59
*** shwetaap has joined #openstack-meeting-304:06
*** hurgleburgler has joined #openstack-meeting-304:30
*** amotoki has joined #openstack-meeting-304:34
*** carl_baldwin has joined #openstack-meeting-304:38
*** shwetaap has quit IRC04:43
*** shwetaap has joined #openstack-meeting-304:43
*** pettori has joined #openstack-meeting-304:52
*** shwetaap has quit IRC04:57
*** pettori has quit IRC05:05
*** carl_baldwin has quit IRC05:07
*** hurgleburgler has quit IRC05:09
*** david-lyle has quit IRC05:10
*** lhcheng has joined #openstack-meeting-305:18
*** lhcheng has quit IRC05:21
*** lhcheng has joined #openstack-meeting-305:21
*** jcoufal has joined #openstack-meeting-305:22
*** david-lyle has joined #openstack-meeting-305:27
*** yamahata has quit IRC05:51
*** yamahata has joined #openstack-meeting-305:52
*** coolsvap is now known as coolsvap|afk06:00
*** coolsvap|afk is now known as coolsvap06:12
*** pkoniszewski has joined #openstack-meeting-306:13
*** mrunge has joined #openstack-meeting-306:13
*** mrunge has quit IRC06:39
*** lhcheng has quit IRC06:40
*** mrunge has joined #openstack-meeting-306:47
*** MaxV has joined #openstack-meeting-306:49
*** MaxV has quit IRC06:55
*** k4n0 has joined #openstack-meeting-306:56
*** flaper87|afk is now known as flaper8706:58
*** k4n0 has quit IRC07:02
*** matrohon has joined #openstack-meeting-307:06
*** ttrifonov_zZzz is now known as ttrifonov07:12
*** k4n0 has joined #openstack-meeting-307:15
*** ttrifonov is now known as ttrifonov_zZzz07:16
*** ttrifonov_zZzz is now known as ttrifonov07:17
*** mrunge has quit IRC07:21
*** mrunge has joined #openstack-meeting-307:29
*** k4n0 has quit IRC07:42
*** MaxV has joined #openstack-meeting-307:44
*** MaxV has quit IRC07:49
*** SumitNaiksatam has quit IRC07:50
*** SumitNaiksatam has joined #openstack-meeting-307:50
*** k4n0 has joined #openstack-meeting-307:55
*** dboik has quit IRC08:00
*** safchain has joined #openstack-meeting-308:00
*** sunrenjie6 has quit IRC08:04
*** sunrenjie has joined #openstack-meeting-308:05
*** yamamoto has quit IRC08:08
*** sunrenjie has quit IRC08:10
*** salv-orlando has joined #openstack-meeting-308:11
*** ttrifonov is now known as ttrifonov_zZzz08:13
*** ttrifonov_zZzz is now known as ttrifonov08:15
*** ttrifonov is now known as ttrifonov_zZzz08:16
*** sunrenjie has joined #openstack-meeting-308:16
*** ttrifonov_zZzz is now known as ttrifonov08:17
*** ttrifonov is now known as ttrifonov_zZzz08:18
*** ttrifonov_zZzz is now known as ttrifonov08:20
*** MaxV has joined #openstack-meeting-308:20
*** david-lyle has quit IRC08:35
*** zz_johnthetubagu is now known as johnthetubaguy09:17
*** sunrenjie has quit IRC09:29
*** coolsvap is now known as coolsvap|afk09:56
*** otherwiseguy has quit IRC09:59
*** yamahata has quit IRC10:19
*** ttrifonov is now known as ttrifonov_zZzz10:20
*** ttrifonov_zZzz is now known as ttrifonov10:22
*** scheuran has joined #openstack-meeting-310:38
*** stanzgy has quit IRC10:52
*** igordcard has joined #openstack-meeting-310:53
*** MaxV has quit IRC11:12
*** MaxV has joined #openstack-meeting-311:12
*** MaxV has quit IRC11:17
*** MaxV has joined #openstack-meeting-311:27
*** amotoki_ has joined #openstack-meeting-311:34
*** amotoki_ has quit IRC11:34
*** otherwiseguy has joined #openstack-meeting-311:38
*** otherwiseguy has quit IRC11:43
*** julim has joined #openstack-meeting-311:45
*** amotoki has quit IRC11:45
*** coolsvap|afk is now known as coolsvap11:46
*** sarob has quit IRC11:46
*** flaviof_zzz has quit IRC11:50
*** bradjones has quit IRC11:59
*** coolsvap is now known as coolsvap|afk12:01
*** markmcclain has joined #openstack-meeting-312:15
*** sarob has joined #openstack-meeting-312:20
*** flaviof_zzz has joined #openstack-meeting-312:22
*** bradjones has joined #openstack-meeting-312:26
*** salv-orlando has quit IRC12:27
*** otherwiseguy has joined #openstack-meeting-312:32
*** otherwiseguy has quit IRC12:37
*** sigmavirus24_awa is now known as sigmavirus2412:49
*** amotoki has joined #openstack-meeting-313:01
*** flaviof_zzz is now known as flaviof13:03
*** jaypipes has joined #openstack-meeting-313:12
*** zz_jgrimm is now known as jgrimm13:13
*** shwetaap has joined #openstack-meeting-313:16
*** otherwiseguy has joined #openstack-meeting-313:26
*** peristeri has joined #openstack-meeting-313:26
*** otherwiseguy has quit IRC13:31
*** markmcclain has quit IRC13:33
*** thangp has joined #openstack-meeting-313:38
*** julim has quit IRC13:47
*** otherwiseguy has joined #openstack-meeting-313:52
*** dboik has joined #openstack-meeting-313:59
*** jgrimm is now known as zz_jgrimm13:59
*** salv-orlando has joined #openstack-meeting-314:10
*** pkoniszewski has quit IRC14:11
*** dt_os has joined #openstack-meeting-314:13
*** otherwiseguy has quit IRC14:16
*** mwagner_lap has joined #openstack-meeting-314:19
*** dboik has quit IRC14:30
*** dboik has joined #openstack-meeting-314:30
*** dt_os has quit IRC14:32
*** hurgleburgler has joined #openstack-meeting-314:33
*** carl_baldwin has joined #openstack-meeting-314:38
*** markmcclain has joined #openstack-meeting-314:41
*** markmcclain has quit IRC14:41
*** k4n0 has quit IRC14:42
*** pkoniszewski has joined #openstack-meeting-314:42
*** markmcclain has joined #openstack-meeting-314:43
*** zz_jgrimm is now known as jgrimm14:46
*** otherwiseguy has joined #openstack-meeting-314:47
*** jschwarz has joined #openstack-meeting-314:51
*** markmcclain has quit IRC14:53
*** gholler has joined #openstack-meeting-314:57
*** gholler_ has joined #openstack-meeting-314:57
*** devvesa has joined #openstack-meeting-314:58
*** yamahata has joined #openstack-meeting-314:58
*** seizadi has joined #openstack-meeting-314:59
*** johnbelamaric has joined #openstack-meeting-315:00
carl_baldwinhi all15:01
jschwarzhi carl :)15:01
carl_baldwinjschwarz: hi15:01
ChuckCo/15:01
jschwarzadded an item to the agenda in case you didn't see it ;p15:01
*** pcm__ has joined #openstack-meeting-315:01
carl_baldwinjschwarz: I did see it.15:01
carl_baldwinthanks15:02
devvesahi15:02
carl_baldwin#startmeeting neutron_l315:02
openstackMeeting started Thu Oct  9 15:02:14 2014 UTC and is due to finish in 60 minutes.  The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot.15:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:02
*** openstack changes topic to " (Meeting topic: neutron_l3)"15:02
openstackThe meeting name has been set to 'neutron_l3'15:02
carl_baldwin#topic Announcements15:02
*** openstack changes topic to "Announcements (Meeting topic: neutron_l3)"15:02
carl_baldwinI don’t think I have any announcements except that Juno RC2 is being work on, I believe.15:03
carl_baldwinAny announcements?15:04
carl_baldwin#topic Bugs15:04
*** openstack changes topic to "Bugs (Meeting topic: neutron_l3)"15:04
*** tidwellr has joined #openstack-meeting-315:04
carl_baldwinI did follow up with more triage since the last meeting.  That was my action item.15:04
carl_baldwinI haven’t seen any concerning bugs pop up since then.15:05
carl_baldwinAre there any bugs that need to be brought up?15:05
matrohonhi! I need one more core review on this : https://review.openstack.org/#/c/116924/15:05
matrohonI'd like it to merge in juno :)15:06
carl_baldwinmatrohon: I’ll add it to my queue.15:06
carl_baldwinmatrohon: Is it tagged for juno potential?15:07
matrohoncarl_baldwin : yes it is tagged. thanks15:07
carl_baldwinok15:07
*** mfer has joined #openstack-meeting-315:07
*** Rajeev has joined #openstack-meeting-315:07
carl_baldwinAny other bugs?15:08
carl_baldwin#topic l3-high-availability15:08
*** openstack changes topic to "l3-high-availability (Meeting topic: neutron_l3)"15:08
carl_baldwinsafchain: amuller: ping15:08
carl_baldwinAnything new here to report or discuss?15:08
jschwarza muller is out o PTO (holiday, i'm no supposed to be here either ;p)15:08
safchainhi15:09
safchainnothing special this week15:09
carl_baldwinsafchain: Thanks.  Feel free to ping me if you need something.15:09
jschwarzI would like to discuss the ns_name issue as it relates to the HA functional tests15:09
safchaincarl_baldwin, thx15:09
jschwarz#link https://review.openstack.org/#/c/123434/2/neutron/agent/l3_agent.py15:10
carl_baldwinjschwarz: almost there.15:10
jschwarzsorry then :)15:10
carl_baldwin#topic bgp-dynamic-routing15:10
*** openstack changes topic to "bgp-dynamic-routing (Meeting topic: neutron_l3)"15:10
carl_baldwindevvesa: ping15:10
devvesacarl_baldwin: hi15:10
carl_baldwindevvesa: good discussions this week.  Any progress on the bp?15:11
devvesabeen busy this morning. I'm considering your idea about promoting ips or networks to advertise them15:11
devvesaalso I think that modeling the edge router is not needed since it is not useful for your use case15:12
carl_baldwindevvesa: One request.  Could you link that testing page that you gave me a link to to the L3 subteam page in the bgp-dynamic-routing section?15:12
devvesasure.15:12
devvesa#link https://wiki.openstack.org/wiki/Neutron/DynamicRouting/TestingDynamicRouting15:13
devvesaoh, now I've read 'to the subteam page' :)15:13
devvesaI'll do15:13
carl_baldwindevvesa: The modelling change that I thought was most important was that advertised routes associate with routers.  Any more thoughts on that?15:13
carl_baldwin#action devvesa will link dynamic routing testing page to subteam page.15:14
devvesato me the advertised routes should be associated to the routing instance, which is the instance that is 'deployed' in the dr_agent15:15
devvesabut we can discuss it more in the spec15:15
*** salv-orlando has quit IRC15:15
carl_baldwindevvesa: Let me think about that a little more.  Maybe I don’t fully understand the scope of the RoutingInstance object.  I’ll review the spec again.15:16
*** jacalcat has joined #openstack-meeting-315:16
carl_baldwinIt still seems natural to associate with the router because the router is what will be handling the route and it has the next hop for the route as a property of the router (its public address).15:17
carl_baldwindevvesa: Thanks for your work on this.15:17
carl_baldwin#topic L3 Agent Refactoring15:17
*** openstack changes topic to "L3 Agent Refactoring (Meeting topic: neutron_l3)"15:17
carl_baldwinjschwarz: hi15:17
jschwarzcarl_baldwin, hi15:18
jschwarzwould be happy if you'd have a look at the link i posted above15:18
carl_baldwinSorry to have ruffled some feathers here.  It seems we have two conflicting efforts going on with the L3 agent.15:18
jschwarzhttps://review.openstack.org/#/c/123434/2/neutron/agent/l3_agent.py15:18
jschwarzthat's quite alright, and I do realise your intentions on this. I realise the current state isn't the best one15:19
jschwarzthe earlier patchset I linked contains what I believe you're looking for15:19
* carl_baldwin is looking at the link15:19
*** amotoki has quit IRC15:20
carl_baldwinjschwarz: I think the property is fine.  I can leave that in.15:20
jschwarzvery well then15:20
carl_baldwinI also see the motivation for _get_router_info from the test you linked.  However, this doesn’t feel quite right.15:20
carl_baldwinCould this work as a static factory method on the RouterInfo class?15:21
jschwarzYou mean, a RounterInfo.create() function which returns what we need?15:21
*** julim has joined #openstack-meeting-315:22
carl_baldwinjschwarz: Yes, something like that.15:22
carl_baldwinIt doesn’t make sense where it is now to me.15:22
jschwarzThis will be problematic since in the functional tests we also change the RouterInfo we create (we override it with a TestRouterInfo, adding the cfg.CONF.host argument)15:22
jschwarzSo a factory function in the RouterInfo namespace will require also overriding functions that create the RouterInfo in the test agent15:23
jschwarz#link https://review.openstack.org/#/c/117994/15/neutron/tests/agents/l3_agent.py15:23
jschwarz:(15:24
carl_baldwinThat test does override it now.  so, it is not a new requirement.  The question is how it overrides it, right?15:25
jschwarzRight. But I think it's better to override a _get_router_info over overriding (and refactoring) _router_added (iirc)15:25
carl_baldwinI have not had the chance to look through the test yet.  I’ll do so today.15:25
jschwarzI'm happy to schedule a sit-down with you on this subject on Monday once we both get a chance to think about this again, if you want :)15:26
carl_baldwinI’ll abandon the reverts that I have up and try to propose something that will meet both our needs.15:26
jschwarzcarl_baldwin, sounds good.15:26
carl_baldwin#action carl_baldwin will abondon reverts and find a better proposal.15:27
jschwarzcarl_baldwin, I'll be happy if you let me write that patch since the functional tests patch depends on the solution we'll implement15:27
carl_baldwinjschwarz: I’ll be in touch.15:27
jschwarzsounds great15:27
jschwarzthanks15:27
*** Swami has joined #openstack-meeting-315:27
carl_baldwinjschwarz: we still have a fundamental problem now in that we have two efforts going on that will be very difficult to coordinate.15:28
Swamihi15:28
carl_baldwinSwami: hi15:28
jschwarzcarl_baldwin, I agree, so we better work on this together15:29
jschwarzcarl_baldwin, the functional tests patch is ready for core review since the smaller patches are all merged - maybe we can consider having the refactoring effort also include the functional tests15:29
carl_baldwinI will post a spec for the refactoring I plan soon (hopefully today)15:30
*** corvus is now known as jeblair15:30
carl_baldwinjschwarz: I will review the tests patch.  Is it just the one patch?15:30
jschwarzyep :) the rest are merged15:31
carl_baldwinjschwarz: Thanks.15:31
yamahatahi, I'm also interested in l3 agent refactoring.15:31
jschwarzthe integration tests are well in the work (will discuss this later) but that's a ways off IMO15:31
carl_baldwinjschwarz: do you plan more work beyond this patch in the near future?15:31
carl_baldwinyamahata: I will add you to the review of the spec.15:31
yamahatacarl_baldwin: can you explain the plan roughly?15:31
carl_baldwinyamahata: It will be better to wait for the spec.  I will try to get it up today.15:32
yamahatacarl_baldwin: got it15:32
jschwarzthe integration tests' first test is planned to be about the HA (since amuller is working closely on this with me and Maru)15:32
matrohoncarl_baldwin : interested too :)15:32
jschwarzbut first the framework has to go through, and a spec, etc... and those aren't up yet15:32
*** BrianB_ has joined #openstack-meeting-315:33
jschwarzcarl_baldwin, you can see the current needs of the integration tests here: https://review.openstack.org/#/c/123000/5/neutron/tests/agents/l3_agent.py15:33
jschwarzbasically, more functions from the original L3 code needs overriding15:33
jschwarzthat said, it's a long way off15:33
*** johnbelamaric has quit IRC15:34
*** cjellick has joined #openstack-meeting-315:34
carl_baldwinjschwarz: I will get more familiar with this work.15:34
carl_baldwinThanks.15:34
*** johnbelamaric has joined #openstack-meeting-315:34
carl_baldwin#topic neutron-ovs-dvr15:35
*** openstack changes topic to "neutron-ovs-dvr (Meeting topic: neutron_l3)"15:35
jschwarzThank you. i'll make sure I add you as a reviewer on all relevant patches and will try to keep this forum involved in the future :)15:35
carl_baldwinjschwarz: That will be great, thanks.15:35
carl_baldwinSwami: hi15:35
Swamihi15:36
carl_baldwinI’m sorry that I missed most of the meeting yesterday.  I had a one-time conflict.15:36
Swamino problems15:36
carl_baldwinAnything to report or discuss?15:36
Swamiregarding DVR there are couple of items that we need to discuss15:36
SwamiThere are two bugs right now, one with respect DB lockwait timeout and the other is triggered because of the DB lockwait timeout15:37
SwamiDB DuplicateError for Snat binding.15:37
SwamiI have posted patches for both these bugs.15:38
Swami#link https://review.openstack.org/#/c/126793/15:38
Swamipatch for the DB Duplicate Error.15:38
*** pkoniszewski has quit IRC15:38
carl_baldwinSwami: Is it ready for review?  Do you need input on it?15:39
SwamiThis patch again introduces the "hints" in the scheduler, since we have a timing issue with respect to Gateway clear and interface-delete, we need to prevent the snat_scheduler being called when there is router_interface-delete, so I am using the hints.15:39
SwamiTake a look at it and let me know.15:39
SwamiI have still address couple of  unit tests on this patch, but I want you to take a look at it.15:40
carl_baldwinSwami: I will.15:40
Swamis/have/have to15:40
carl_baldwinI have been meaning to get to it.15:40
SwamiAlso on the DB lockwait timeout issue, there is patch out there15:40
carl_baldwin#action carl_baldwin will review https://review.openstack.org/#/c/126793/15:41
Swami#lin https://review.openstack.org/#/c/127129/15:41
Swami#link https://review.openstack.org/#/c/127129/15:41
SwamiThis patch also needs your attention.15:41
carl_baldwin#action carl_baldwin will review https://review.openstack.org/#/c/127129/15:42
*** scheuran has quit IRC15:42
carl_baldwinSwami: I have had these on my list to look at.  I will bump them up to the top.15:42
* carl_baldwin wonders where the time goes15:42
*** stevelle has left #openstack-meeting-315:42
SwamiAlso I have posted a WIP patch for the VPN with DVR.15:42
carl_baldwinSwami: Thank you for the links.15:42
Swami#link https://review.openstack.org/#/c/127133/15:42
SwamiLast week we had an action item to create a Wiki to start adding notes for the HA and DVR with Service node.15:43
Swami#link https://wiki.openstack.org/wiki/Neutron/DVR/ServiceNode-HA15:43
carl_baldwinSwami: A new one I have not seen yet.15:43
Swamicarl_baldwin: yes this is a new one, since armando abandoned the VPN patch that prevents someone from configuring the VPN for DVR, I started working on this patch.15:44
SwamiNow with DVR the IPsec reference implementation should work.15:44
carl_baldwinSwami: that will be good.15:45
Swamicarl_baldwin: I will work on the "Migration comments" that you made and try to push a patch.15:45
carl_baldwinThanks for the HA/DVR wiki page link too.  That will be an important improvement.15:45
SwamiThat's all I have from the DVR side.15:45
carl_baldwinSwami: How many of you are there?  ;)15:45
SwamiAlso rajeev is back from vacation and I will ask him to take a look at the IPv6.15:46
carl_baldwinSwami: Thanks for the report.15:46
*** johnbelamaric has quit IRC15:46
SwamiRight now it's only me and rajeev just joined me today.15:46
*** johnbelamaric has joined #openstack-meeting-315:46
* carl_baldwin was just kidding15:47
carl_baldwinSwami: Great work.  Thanks.15:47
carl_baldwin#topic Open Discussion15:47
*** openstack changes topic to "Open Discussion (Meeting topic: neutron_l3)"15:47
carl_baldwinI think that is all I wanted to cover today.15:47
carl_baldwinAnything else?15:47
SwamiI am done, nothing else.15:47
jschwarzSurprisingly, none from me :)15:47
pcm__is there a link with an overview of the plans for refactorings?15:47
* pcm__ trying to catch up15:48
carl_baldwinpcm__: Not yet, I’m hoping to get a spec up today.  If not today then tomorrow.15:48
carl_baldwin#action carl_baldwin will put up a spec detailing l3 agent refactoring goals.15:48
pcm__carl_baldwin: cool. Interested in that effort as well15:48
jschwarzwill be happy if you could also add me as a reviewer for that15:48
carl_baldwinjschwarz: I will.15:48
pcm__me too15:48
matrohoncarl_baldwin : I wonder if you plan to resubmit pluggable-ext-net in kilo15:48
carl_baldwinpcm__: Will add you too.15:48
*** otherwiseguy has quit IRC15:48
matrohonhttps://review.openstack.org/#/c/88619/5/specs/juno/pluggable-ext-net.rst15:49
carl_baldwinmatrohon: Yes, I do.  That is important work for me and I will resubmit it soon.  It will benefit greatly from some refactoring.15:49
matrohoncarl_baldwin : good to know thanks15:49
matrohonis there anybody around still interested in BGPVPN?15:50
matrohonhttps://review.openstack.org/#/c/93329/15:50
*** johnbelamaric has quit IRC15:51
carl_baldwinmatrohon: devvesa mentioned a possible pod session or something at the conference.15:51
Swamiyes I will be interested in BGPVPN15:51
devvesamatrohon: yes, I would like to reserve a pod during the summit to talk about BGP and BGPVPN15:51
carl_baldwindevvesa: loop in Swami and matrohon for that discussion.15:52
matrohoncarl_baldwin, devvesa, Swami : great, there is a natural overlap devvesa work15:52
matrohonpods are exclusively on friday?15:53
devvesano15:53
devvesaI think there will be pods available all the design session days15:54
devvesahowever, even the design sessions are not defined yet (at least in the sched site)15:54
SwamiIf we don't want to miss the design session then we can book the pod on friday to have our discussion15:54
devvesaOk. I'll reserve on friday15:55
matrohonfine, one of the main contributor on BGP stuff in our team will attend the summit only untill thurday mornig15:55
matrohonfriday won't match with his planning :(15:55
devvesaouch15:55
carl_baldwinLet’s wait a bit for the rest of the schedule to come out.  We’ll have a better idea of when we can fit it in.15:56
*** markmcclain has joined #openstack-meeting-315:56
matrohonthere is no design session wednesday pm for neutron15:56
matrohonfor the moment15:56
matrohonif i do remember well :)15:56
devvesaYes, let's wait. I'll ping all of you via IRC before reserve the pod and see your availability , ok?15:57
matrohonhttp://kilodesignsummit.sched.org/overview/type/neutron#.VDawUps7vmE15:57
matrohondevvesa : fine15:57
carl_baldwindevvesa: Okay.15:57
*** markmcclain1 has joined #openstack-meeting-315:58
carl_baldwinThanks everyone.  I’m looking forward to Kilo and the summit.15:59
carl_baldwin#endmeeting15:59
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"15:59
openstackMeeting ended Thu Oct  9 15:59:15 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:59
openstackMinutes:        http://eavesdrop.openstack.org/meetings/neutron_l3/2014/neutron_l3.2014-10-09-15.02.html15:59
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/neutron_l3/2014/neutron_l3.2014-10-09-15.02.txt15:59
openstackLog:            http://eavesdrop.openstack.org/meetings/neutron_l3/2014/neutron_l3.2014-10-09-15.02.log.html15:59
devvesabye!15:59
jschwarzbye guys :)15:59
*** lhcheng has joined #openstack-meeting-316:00
jschwarzcarl_baldwin, I'll be off for the rest of the week so i'll try to catch you on monday and see if we can work something out :)16:00
jschwarzhave a nice weekend guys16:00
*** markmcclain has quit IRC16:00
pcm__bye16:00
carl_baldwinjschwarz: okay16:00
carl_baldwinThanks16:00
*** pcm__ has left #openstack-meeting-316:00
*** jschwarz has quit IRC16:00
carl_baldwinHave a great weekend16:00
*** otherwiseguy has joined #openstack-meeting-316:02
*** markmcclain1 has quit IRC16:03
*** johnbelamaric has joined #openstack-meeting-316:03
*** armax has joined #openstack-meeting-316:03
*** markmcclain has joined #openstack-meeting-316:04
*** devvesa has quit IRC16:04
*** johnbelamaric has quit IRC16:06
*** johnbelamaric_ has joined #openstack-meeting-316:06
*** yamahata has quit IRC16:06
*** safchain has quit IRC16:07
*** lhcheng has quit IRC16:08
*** lhcheng has joined #openstack-meeting-316:09
*** carl_baldwin has quit IRC16:11
*** SridarK has quit IRC16:12
*** matrohon has quit IRC16:12
*** lhcheng has quit IRC16:13
*** cbader has joined #openstack-meeting-316:15
*** igordcard has quit IRC16:16
*** robcresswell has joined #openstack-meeting-316:22
*** MaxV has quit IRC16:24
*** johnbelamaric_ has quit IRC16:24
*** johnbelamaric_ has joined #openstack-meeting-316:25
*** robcresswell has left #openstack-meeting-316:25
*** johnbelamaric_ has quit IRC16:26
*** david-lyle has joined #openstack-meeting-316:26
*** peristeri has quit IRC16:30
*** peristeri has joined #openstack-meeting-316:32
*** otherwiseguy has quit IRC16:35
*** peristeri has quit IRC16:40
*** peristeri has joined #openstack-meeting-316:40
*** pettori has joined #openstack-meeting-316:42
*** igordcard has joined #openstack-meeting-316:45
*** bradjones has quit IRC16:46
*** s3wong has joined #openstack-meeting-316:47
*** carl_baldwin has joined #openstack-meeting-316:51
*** johnthetubaguy is now known as zz_johnthetubagu16:52
*** sigmavirus24 has left #openstack-meeting-316:57
*** Youcef has joined #openstack-meeting-317:04
*** salv-orlando has joined #openstack-meeting-317:08
*** alexpilotti has joined #openstack-meeting-317:23
*** lhcheng has joined #openstack-meeting-317:34
*** jcoufal has quit IRC17:35
*** peristeri has quit IRC17:40
*** ivar-lazzaro has joined #openstack-meeting-317:40
*** SumitNaiksatam has quit IRC17:40
*** seizadi has quit IRC17:42
*** peristeri has joined #openstack-meeting-317:45
*** otherwiseguy has joined #openstack-meeting-317:46
*** lhcheng has quit IRC17:49
*** lhcheng has joined #openstack-meeting-317:49
*** peristeri has quit IRC17:51
*** mrunge has quit IRC17:51
*** lhcheng has quit IRC17:54
*** gholler_ has quit IRC17:55
*** gholler has quit IRC17:55
*** sigmavirus24 has joined #openstack-meeting-317:56
*** jacalcat has left #openstack-meeting-317:56
*** glebo has joined #openstack-meeting-317:58
*** rkukura has joined #openstack-meeting-317:59
*** SumitNaiksatam has joined #openstack-meeting-318:00
SumitNaiksatamhi18:00
rkukurahi18:00
ivar-lazzarohi18:01
s3wonghello18:01
SumitNaiksatamrkukura: ivar-lazzaro s3wong: hi18:01
gleboyo18:01
*** yyywu has joined #openstack-meeting-318:01
SumitNaiksatamlets get started18:01
SumitNaiksatamglebo: hi18:01
*** shakamunyi has joined #openstack-meeting-318:01
*** shakamunyi has quit IRC18:01
SumitNaiksatam#startmeeting networking_policy18:01
openstackMeeting started Thu Oct  9 18:01:54 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.18:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:01
*** openstack changes topic to " (Meeting topic: networking_policy)"18:01
openstackThe meeting name has been set to 'networking_policy'18:01
SumitNaiksatam#info agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy18:02
SumitNaiksatam#chairs s3wong ivar-lazzaro rkukura18:02
SumitNaiksatamjust in case i lose connectivity18:02
SumitNaiksatam#topic Patches in review18:03
*** openstack changes topic to "Patches in review (Meeting topic: networking_policy)"18:03
SumitNaiksatam#link #link https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy+branch:master,n,z18:03
SumitNaiksatamthe above are the server side patches which we are focussing on for now18:03
SumitNaiksatamthe good news is that we got some patches merged over the last few days18:04
SumitNaiksatamthanks to all the reviewers!18:04
s3wongimplicit driver is next in the chain18:04
SumitNaiksatams3wong: yes, thanks for the reviews18:04
SumitNaiksatamthe GBP redirect to service chain patches have also been pushed18:05
*** hemanthravi has joined #openstack-meeting-318:05
SumitNaiksatami notice that multiple patches are in review18:05
SumitNaiksatamthe spec is also in review, so we need to get the spec reviewed, approved, merged first18:05
SumitNaiksatamhemanthravi: good timing ;-(18:05
SumitNaiksatamoopps i meant ;-)18:05
hemanthravihi18:06
hemanthravi:)18:06
*** nbouthors has joined #openstack-meeting-318:06
SumitNaiksatamso taking a step back…how is the stackforge process coming along, in terms of pusing patches for reviews, and reveiwing?18:06
SumitNaiksatamanyone face any issues, or things we need to change?18:06
SumitNaiksatamwe are following the standard openstack process (so its not new)18:07
SumitNaiksatamhopefully we can get out of the long-chain-of-dependencies mode pretty soon18:07
SumitNaiksatamand not have to spent the rest of lives rebasing! ;-)18:08
hemanthraviwill resume reviews from my side18:08
SumitNaiksatamhemanthravi: thanks18:08
SumitNaiksatamlets tackle the service chain spec review as a separate topic, i forgot to add it to the agenda18:08
SumitNaiksatamivar-lazzaro: rkukura: anything else we need to discuss in terms of the patches that are in review? (we will discuss DB schema and resource mapping driver refactoring separately)18:09
rkukuranothing I can think of18:09
SumitNaiksatamrkukura: okay18:09
ivar-lazzaroSumitNaiksatam: nope18:10
SumitNaiksatambtw, i forgot to mention, Ronak mentioned that he cannot make it to the meeting today, and i believe banix is still off work18:10
SumitNaiksatamivar-lazzaro: okay18:10
SumitNaiksatam#topic GBP DB18:10
*** openstack changes topic to "GBP DB (Meeting topic: networking_policy)"18:10
gleboSumit: "meeting today" = this meeting, or some other meetup?18:11
SumitNaiksatamglebo: ah, i meant this meeting18:11
glebosumit: ack18:11
glebothx18:11
SumitNaiksatamivar-lazzaro: so you posted the separate schema patch?18:11
SumitNaiksatam#link https://review.openstack.org/#/c/126383/18:12
ivar-lazzaroSumitNaiksatam: yes, as it was mentioned in the ML discussion there are roughly two ways of addressing this18:12
SumitNaiksatamivar-lazzaro: okay18:12
SumitNaiksatamivar-lazzaro: so we for Juno we have decided to go with a separate DB so as not to break neutron migrations?18:12
ivar-lazzaroSumitNaiksatam: Different Schema Different Chain (DSDC) or Same Schema Different Chain (SSDC)18:12
SumitNaiksatamivar-lazzaro: :-)18:13
ivar-lazzaroSumitNaiksatam: we definitively know that we need to have a different chain18:13
rkukuraI thought we prefered a separate chain in the same DB?18:13
ivar-lazzaroSumitNaiksatam: My patch proposes a different schema approach (the other is trivial)18:13
rkukuraSSDC18:13
rkukuraany downside to the trivial option?18:14
rkukuracreating a separate DB means extra work for deployment tools, etc.18:14
ivar-lazzarorkukura: yes, we still risk that packagers could have some problems with that18:14
ivar-lazzarorkukura: because we are touching a core project DB18:14
ivar-lazzarorkukura: even though we are only adding tables18:15
ivar-lazzarorkukura: the separate schema approach is the safest, no turnarounds whatsoever18:15
rkukuraWe are building a service plugin right now, and we have foriegn keys on the existing core tables, so this just seems like the easier/safer option to me.18:15
SumitNaiksatamivar-lazzaro: you mean the risk is with SSDC?18:15
ivar-lazzaroSumitNaiksatam: yeah that's the risk with same schema18:15
rkukuraA separate schema seems to mean more DB connections from the server, possibility of some DB’s not supporting it, and deployment tools needing to create extra DBs and configure their URLs into neutron.conf.18:16
ivar-lazzarorkukura: DBMSs are made so there's no actual difference from a schema to another... it's just namespacing18:16
ivar-lazzarorkukura: so there are no performance issues in having a different schema18:16
rkukuraivar-lazzaro: According to the guy from Red Hat who maintains sqlalchemy, that is the case for mysql, but not necessarily for other DBs18:17
ivar-lazzarorkukura: why do we need new deployment tools? our migration will do the trick18:17
*** carl_baldwin has quit IRC18:17
rkukurapuppet scripts need to create the new DBs, set their owners, put their URLs in neutron’s conf file, ...18:17
ivar-lazzarorkukura: I would say that being safe on the packaging perspective is our top priority... Maybe we can verify that the implementation works with other DBMS18:17
rkukuraSSDC is much safer from a packaging perspective18:18
ivar-lazzarorkukura: yeah and that happens for any Stackforge Project18:18
ivar-lazzarorkukura: In my experience with RH, adding tables to the existing Neutron DB is actually a problem (backport of apic driver)18:19
rkukuraThis stackforge project is a service plugin that may eventually become part of neuton - I don’t see why we want to add complexity that is not needed.18:19
ivar-lazzarorkukura: if for some reason they add a gbp_endpoint table in Kilo, the migration will fail when you upgrade18:19
SumitNaiksatamrkukura: agreed, but it seems that some of the discussions around packaging have indicated that adding tables to the same neutron schema raises eyebrows with the distro folks18:19
rkukuraThe backport issue is due to the single linked list chain of migtrations, right?18:19
ivar-lazzarorkukura: right, but I want to make sure that the separate chain is enough18:20
ivar-lazzarorkukura: I have no preference whatsoever, I just want to make sure our stuff can be packaged and used by people18:20
ivar-lazzarorkukura: so the approach that maximizes this wins for me18:20
rkukuraAdding a separate DB requires much more code change and support in the deployment tools. I don’t see why we aren’t just going with the simple solution.18:20
ivar-lazzarorkukura: I'm aiming for the safest, not the simpliest18:21
rkukuraivar-lazzaro: Do you have examples of how adding a new chain of migrations in the same DB might cause difficulty for deployment tools?18:21
ivar-lazzarorkukura: yes, let's say that in Kilo someone adds a table with the same name as ours18:22
ivar-lazzarorkukura: (even us if we get merged)18:22
rkukuraAre you 100% sure that managing multiple DB connections in the same neutron process works correctly with greenthreads and all that?18:22
ivar-lazzarorkukura: then the migration Juno -> Kilo will fail because of duplication of tables18:22
rkukuraivar-lazzaro: If someone adds a table containing the string “gbp”, I will -2 it18:22
ivar-lazzarorkukura: what if we add it when we merge into neutron?18:23
SumitNaiksatamrkukura: ;-)18:23
ivar-lazzarorkukura: I understand we need to take some more time validating that the approach scales and works with as many DBMS as possible18:23
SumitNaiksatamrkukura: if we can get an assurance from the distro folks that adding tables to the neutron schema is fine, i think we can go the SSDC route, however i think they have been apprehensive to this point18:24
ivar-lazzarorkukura: but imho it's worth the effort if we are then 100% sure that packagers won't complain18:24
rkukuraivar-lazzaro: If we add it, we’ll need to think about what works best for our existing users. Maybe making the upgrade migration check if the tables already exist would solve it.18:24
ivar-lazzarorkukura: that requires a core change in Neutron (even alembic maybe)18:24
*** peristeri has joined #openstack-meeting-318:24
rkukuraI think packagers will have more work to do if there are additional DBs to create and configure.18:24
ivar-lazzaroSumitNaiksatam: +1, if we make sure that it's ok with them, I'm all for it18:25
rkukuraivar-lazzaro: Are you sure a migration cannot be written to  check if the table exists?18:25
SumitNaiksatamivar-lazzaro: also, i recall that there was something about there being only a single DB revision table that was causing issues?18:25
ivar-lazzarorkukura: I guess you can do that in the migration file18:26
ivar-lazzaroSumitNaiksatam: that is easy to solve, you just add a new versioning table18:26
*** garyduan has joined #openstack-meeting-318:26
ivar-lazzarorkukura SumitNaiksatam: do we agree that we can go with SSDC if distro guys bless the approach?18:27
rkukuraNote that I did add a -1 and a comment with my view on this to https://review.openstack.org/#/c/126383/. Thats where we should be having this discussion.18:27
rkukuraivar-lazzaro: I’m convinced either will work - just want to figure out which is best from various points of view18:28
*** cathy_ has joined #openstack-meeting-318:28
gleborkukura: newbie question here: you say "existing users" how many of these do we think we have for GBP?18:28
ivar-lazzarorkukura: actually if we were 100% sure that distro guys are ok I would just go with SSDC18:28
ivar-lazzarorkukura: in fact, it's simpler code and more intuitive approach18:29
ivar-lazzarorkukura: but packaging has the top priority for me18:29
rkukuraglebo: If and when we get to the point of merging GBP into neutron, I think it will be largely because we’ve got existing users of our stackforge implementation.18:29
*** pettori has quit IRC18:30
SumitNaiksatamrkukura: ivar-lazzaro: okay lets try to close on this by tomorrow (by checking with the distro/packagin folks)18:30
*** LouisF has joined #openstack-meeting-318:30
rkukuraivar-lazzaro: I’ve also got concerns about whether DSDC works with postgresql, db2, etc.18:30
ivar-lazzaroSumitNaiksatam: I don't know many of them :) who can follow up? Maybe we should ask guidance to Ihar18:30
ivar-lazzarorkukura: that has to be validated indeed18:31
gleborkukura: and how many are there today?18:31
SumitNaiksatamivar-lazzaro: yes, i thought we were already talking to him18:31
rkukuraivar-lazzaro: no data that it doesn’t, just the sqlalchemy maintain’s advice that DBs differ in this18:31
ivar-lazzarorkukura: I hope it's not that hard18:31
*** pettori has joined #openstack-meeting-318:31
SumitNaiksatamanyone else have thoughts or opinions on this?18:32
rkukuraglebo: We don’t have enough functionality merged to the stackforge repos yet for their to be any existing users, but hopefully soon ;)18:32
rkukuraseems like following up with the sqlalchemy maintainer and maybe someone familiar with the puppet scripts would make sense.18:33
gleborkukura: indeed. So, if current user count is low, then maybe user impact is not germaine at this point?18:33
SumitNaiksatamglebo: i think rkukura’s point is that we expect users to adopt this once we have this in stackforge18:34
rkukuraglebo: agreed that we aren’t talking about current users as of today. I think we were talking about at the end of kilo or in the L cycle.18:34
SumitNaiksatamglebo: and the expect them keep using this, regardless of where GBP ends up18:34
SumitNaiksatamglebo: so our approach needs to be non-disruptive for them (or at least we have to try)18:34
cathy_rkukura: SumitNaiksatam: I have a related question to glebo's quesiton. Currently GBP is developed in Stackforge. Are we still  targeting GBP for the Openstack K release?18:35
SumitNaiksatamglebo: but your point well taken as well, i guess we need to weigh the pros and cons18:35
SumitNaiksatamcathy_: GBP is definitely targeted for K release as well18:35
gleborkukura SumitNaiksatam: so the impact is more from the perspective of the existing OS users who would merge GBP to their existing Neutron deployments, more so than for stackforge GBP users?18:35
SumitNaiksatamcathy_: what will be its eventual home is not clear at this point18:36
rkukuracathy_: I’m not very hopeful of GBP getting merged into neutron during kilo, but I do expect our repos to be used with kilo.18:36
SumitNaiksatamcathy_: for Juno its being release via stackforge18:36
SumitNaiksatam*released18:36
SumitNaiksatamglebo: at the moment existing users == stackforge GBP users :-)18:37
SumitNaiksatamcathy_: did that answer your question?18:37
rkukuraThis brings up the issue of branching within our stackforge repos. At some point, I think we’ll need a branch that tracks stable-juno and another branch that tracks master.18:37
cathy_Is it widely known to users that they can use GBP in Stackforge ?18:37
SumitNaiksatamrkukura: yes good point18:37
gleborkukura: +1, sadly so. The priorities for Kilo have been stated VERY clearly by the TC: Neutron stability and closing gap for the eventual deprecation of Nova-networking. Not clear to me that anything outside of those stated goals will get much air time in Kilo18:37
ivar-lazzarorkukura: +118:37
SumitNaiksatam#action SumitNaiksatam to explore branching for stackforge projects18:38
cathy_SumitNaiksatam: yes. thanks for your answer.18:38
rkukuracathy_: our plan is to get the stackforge repos into a useable state before the kilo summit, and do our best their to raise awareness18:38
s3wongglebo: I think that was the primary reason for GBP not able to land in Juno as well18:38
LouisFSumitNaiksatam: what are plans for gbp meetings at the summit?18:39
glebos3wong: ack. And, depending on progress toward that goal, may be used again in L18:39
SumitNaiksatamcathy_: this has been discussed in ML, any reason to believe that users are still not aware of this?18:39
s3wongSumitNaiksatam: rkukura: in terms of advertising this during the K-Summit... other than our conference presentation, is there anything else? I mean, do we have a booth? :-)18:39
SumitNaiksatamLouisF: yes we will defintiely be meeting18:39
LouisFSumitNaiksatam: any sessions on gbp?18:40
glebowe're off on a few tangents. Did we yet close the SSDC vs DSDC topic?18:40
SumitNaiksatamglebo: good point18:40
SumitNaiksatamLouisF: lets circle back to this in the open discussion18:40
SumitNaiksatamglebo: we will close on SSDC versus DSDC by tomorrow based on distro/packagers input18:41
s3wongglebo: I believe the conclusion there is if same schema is OK with release and packaging folks, we will go with SSDC  --- that is my understanding so far18:41
SumitNaiksatam#action ivar-lazzaro to send update to ML based on decision by tomorrow18:41
glebos3wong SumitNaiksatam: wfm18:41
SumitNaiksatam#topic Resource Mapping driver refactoring proposal18:42
*** openstack changes topic to "Resource Mapping driver refactoring proposal (Meeting topic: networking_policy)"18:42
glebos3wong SumitNaiksatam: thx for clarifying18:42
SumitNaiksatamivar-lazzaro: another item for you ;-)18:42
ivar-lazzaroSumitNaiksatam: yeee18:42
SumitNaiksatamivar-lazzaro: i believe you have posted a LP BP for this18:42
ivar-lazzaroSumitNaiksatam: So I proposed a BP18:42
SumitNaiksatam#link https://blueprints.launchpad.net/group-based-policy/+spec/mapping-extension-refactor18:42
ivar-lazzaroSumitNaiksatam: #link https://blueprints.launchpad.net/group-based-policy/+spec/mapping-extension-refactor18:42
ivar-lazzaroyeah that one18:43
SumitNaiksatamivar-lazzaro: thanks, but i beat you ;-P18:43
ivar-lazzaroSumitNaiksatam: ;)18:43
SumitNaiksatamivar-lazzaro: so we will wait for the more detailed spec18:43
SumitNaiksatamivar-lazzaro: in the meanwhile can you please quickly summarize in which direction you are going?18:43
ivar-lazzarosure18:43
*** carl_baldwin has joined #openstack-meeting-318:43
rkukuraivar-lazzaro: This is more radical than I expected - are you suggesting dropping the other mapping attributes, or just moving them to a different extension?18:43
SumitNaiksatamivar-lazzaro: i think the vendor drivers  will be interested in knowing about this18:43
ivar-lazzarorkukura: the main extension should be PT->Port18:44
ivar-lazzarorkukura: everything else can be implicit, or different extension18:44
ivar-lazzaroSo the rationale behind the proposal is that we want to expose a common mapping API18:44
rkukuraivar-lazzaro: I was considering including that part in a base-mapping extension in https://blueprints.launchpad.net/group-based-policy/+spec/gbp-extension-drivers18:44
ivar-lazzarothat user knows is the common denominator between mapping drivers18:44
SumitNaiksatamso ivar-lazzaro are you proposing to remove all other mapping?18:45
rkukuraivar-lazzaro: I think this does kind of make sense, especially if policy drivers can have corresponding extension drivers that expose their specific mapping attributes18:45
ivar-lazzaroThe extension we have now is complex and set a very big constraint on how drivers should map the GBP model18:45
ivar-lazzaroAlso, showing constructs like Network/Subnet/Router may be not very useful, especially in write mode18:46
rkukuraBut I’m a bit concerned that this kind of blocks any possibility of GBP supporting multiple policy drivers simultaneously in the future.18:46
ivar-lazzaroSo my proposal is that our main GBP mapping extension (common one) is PT->Port RO18:47
ivar-lazzarothis is needed by Nova18:47
SumitNaiksatamivar-lazzaro: but to create the port you need all the other mapping as well, right?18:47
ivar-lazzaroand gives the drivers the capability to do whatever mapping they want implicitly, or using extension for explicit mapping as per rkukura proposal18:47
rkukuraivar-lazzaro: I think you and I are agreeing pulliing PT->port into a base-mapping extension makes sense. Others?18:47
* s3wong already confused by PT --- forgot that EP is now policy target...18:47
ivar-lazzaros3wong: :)18:48
ivar-lazzaroSumitNaiksatam: you do, but don't confuse DB with API18:48
ivar-lazzaroSumitNaiksatam: you can do whatever you want in the backend without exposing it to the outside world18:48
rkukuraivar-lazzaro: I thought your proposal was going to be more around factoring out code from resource_mapping driver that other drivers can use.18:48
ivar-lazzaroSumitNaiksatam: and I don't see any compelling need to expose those constructs (besides port)18:48
SumitNaiksatamivar-lazzaro: rkukura: i think you folks have thought about this more than i have, so i need to see the spec or the patch18:48
SumitNaiksatamrkukura: that was my initial understanding as well18:49
ivar-lazzarorkukura: that is a direct consequence. We converge in a common mapping extension (used by the reference implementation) and then we add extensions18:49
SumitNaiksatamrkukura: seems like we are leapfroggin :-)18:49
s3wongrkukura: agreed... that was the item we talked about during the hackathon: which is factoring out implicit driver for EP/EPG/L2P/L3P for a common piece where other policy drivers can use18:49
ivar-lazzaros3wong: that is a different item, that's about our code architecture per se18:50
ivar-lazzaros3wong: what I'm bringing up here is about the minimal API we need to set as GBP "standard"18:50
rkukuras3wong: The implicit_policy driver is already totally separate from any specific mapping, so it should be useable with any policy driver.18:50
ivar-lazzaroThis will help users moving from a driver to another without issues (or even using them together)18:50
*** bpokorny has joined #openstack-meeting-318:51
s3wongivar-lazzaro: I see --- so you are thinking of making anything other than EP/EPG to be non-mandatory...18:51
ivar-lazzarorkukura: s3wong: the implicit policy driver is fine18:51
ivar-lazzaros3wong: only EP -> Port will be standard18:51
ivar-lazzaros3wong: any other mapping will be decided by the driver itself18:51
s3wongivar-lazzaro: not even EPG, huh? I guess you don't want to always map it to a subnet18:51
rkukuraIs there a need for an additional BP covering refactoring the resource_mapping driver code, such as the functions to create ports, subnets, networks, etc., into a class that any driver can inherit or compose?18:51
ivar-lazzaros3wong: abstracting is the whole point of GBP in fact ;)18:51
ivar-lazzarorkukura: yes, that is also useful, but we can discuss that separately18:52
SumitNaiksatamrkukura: sure, however we need to optimize on the available time as well18:52
rkukuraSo this discussion is on the API.18:52
ivar-lazzaroWhat I'm saying is... Is there a compelling need for exposing the full mapping?18:52
ivar-lazzaroIf not, we should do the simpler 5% effort solution which covers 90% of use cases18:53
s3wongivar-lazzaro: but that does have an impact on the mapping DB, right?18:53
rkukuraI’d think that, given the port, a user could navigate to the subnet and network, right?18:53
ivar-lazzarorkukura: correct18:53
SumitNaiksatamrkukura: ivar-lazzaro agree18:53
ivar-lazzarorkukura: so if we exclude the "write" capabilities, we don't have any need for exposing a more complex model which constraints future drivers18:54
SumitNaiksatamivar-lazzaro: i guess you are trying to move away from forcing the users of the current mapping extension to do the mapping to routers, subnets, etc.18:54
rkukurathe PT->port mapping is clearly read-only, right?18:54
SumitNaiksatamivar-lazzaro: and only limit to ports18:54
ivar-lazzaroMy feeling is that nobody will even even need mapping extensions in a first place! unless they want to provide Write capabilities18:54
ivar-lazzarorkukura: correct18:55
SumitNaiksatamivar-lazzaro: if i recollect one of the original goals was to provide both neutron and GBP APIs concurrently18:55
SumitNaiksatamivar-lazzaro: i am not sure if that holds true, we should check on that18:55
rkukuraI see little risk in splitting the existing mapping extension into a base-mapping extension that just covers PT->port, and a resource-mapping extension that exposes the rest of the attributes.18:55
SumitNaiksatamivar-lazzaro: okay we need some more offline discussion on this18:55
s3wongivar-lazzaro: it is an interesting take on the idea that some part of mapping driver can be used by other policy-driver; when we set off with mapping driver, it was meant to be a reference implementation18:55
SumitNaiksatamwe have 5 minutes remaining18:55
ivar-lazzaros3wong: the mapping DB right now is what the main plugin inherits from... And that shouldn't be the case! So a refactor there is needed as well18:55
SumitNaiksatamlets circle back to the earlier topic18:55
SumitNaiksatam#topic Open Discussion18:56
*** openstack changes topic to "Open Discussion (Meeting topic: networking_policy)"18:56
SumitNaiksatamLouisF: you asked about GBP session in the Paris summit18:56
ivar-lazzaros3wong: but that's a problem we have anyway if we want to give drivers the ability to map their own stuff without writing a new Plugin18:56
rkukuraivar-lazzaro: My BP will move the build in mapping extension to an extension driver.18:56
s3wongivar-lazzaro: and of course now you are taking it to the extreme where you assume most vendor policy-driver will be using some parts of mapping driver18:56
LouisFSumitNaiksatam: yes18:56
ivar-lazzarorkukura: nice! So our combined effort will solve this problem and give a much nicer API18:56
SumitNaiksatamso we have a conference session/presentation: #link https://openstacksummitnovember2014paris.sched.org/event/3381db355f042c612c11960a588e31de18:57
rkukuraivar-lazzaro: I kind of agree, but we do need to get the rest of the team thinking about this, which I think we’ve accomplished18:57
ivar-lazzaros3wong: No that's the whole point, vendor drivers will most certainly only need PT->Port mapping18:57
SumitNaiksatamLouisF: was your question targeted at a desgin summit session?18:57
ivar-lazzaros3wong: and that's all we have to give them18:57
s3wongivar-lazzaro: rkukura: I agree that if the intent is to let 3rd party policy driver to leverage mapping driver, the ML2 like framework thing rkukura proposes seems like a good step18:57
LouisFboth18:57
SumitNaiksatamivar-lazzaro: rkukura s3wong: can we continue the discussion after the meeting, we have changed the topic18:57
ivar-lazzaros3wong: with this proposal I'm in fact enhancing the flexibility of future drivers18:57
SumitNaiksatamLouisF: so as far the design summit session is concerned, that is not decided yet18:58
SumitNaiksatamLouisF: the wishlist for Neutron looks like this: #link https://etherpad.openstack.org/p/kilo-neutron-summit-topics18:58
SumitNaiksatamLouisF: we have also requested a session for GBP in the “other projects” track but we are not sure we will get that18:58
s3wongSumitNaiksatam: and my understanding is ... even the pods are very limited in time-sharing in this summit18:58
SumitNaiksatams3wong: okay18:59
s3wongSumitNaiksatam: I heard somewhere (from mestery, I believe) that Neutron pods will only be available on Friday?18:59
SumitNaiksatamLouisF: short of anything else, i propose that we will at least have an uncoference session18:59
SumitNaiksatams3wong: yes the schedule seems to suggest that18:59
SumitNaiksatam*unconference18:59
LouisFSumitNaiksatam: thx18:59
SumitNaiksatamLouisF: and of course open to other suggestions/ideas19:00
s3wongMost likely, we need to grab a room somewhere that isn't pod/Neutron related, and meet at a mutual time there19:00
SumitNaiksatamanyone else have any other thoughts on these logistics?19:00
SumitNaiksatams3wong: yes19:00
SumitNaiksatamand this is going to be the case for a lot of other features/new projects19:00
gleboivar-lazzaro s3wong rkukura: a summary of where you all converged on the mapping topic would be great, either here or in subsequent room19:00
SumitNaiksatamsince the agenad is heavily oversubscribed19:00
rkukuras3wong: We need to check on that. My understanding was the pods were available all week, but most of friday was dedicated to informal discussions rather than scheduled sessions19:00
SumitNaiksatamglebo: yes, this will be posted to the ML19:01
ivar-lazzaroglebo: I'll propose a spec very soon and we can continue the discussion there19:01
s3wongrkukura: OK? because if not, that would be even worse than the good old unconference days19:01
SumitNaiksatam#action ivar-lazzaro rkukura to send update to ML on #link https://blueprints.launchpad.net/group-based-policy/+spec/mapping-extension-refactor and #link https://blueprints.launchpad.net/group-based-policy/+spec/gbp-extension-drivers19:01
rkukuraglebo: And I’ll be posting the spec for https://blueprints.launchpad.net/group-based-policy/+spec/gbp-extension-drivers19:02
s3wongrkukura: but it seems like there are some dedicated "cross-projects" stuff over the first few days for the pod area?19:02
SumitNaiksatamokay we are a couple of minutes over19:02
SumitNaiksatamanything else that anyone wants to urgently bring up?19:02
*** bpokorny_ has joined #openstack-meeting-319:02
s3wongSumitNaiksatam: we should start working on the presentation via email?19:02
s3wongSumitNaiksatam: now that banix will likely not join us...19:03
SumitNaiksatams3wong: yes, i have an AI to add the policy summit slides to mandeep’s earlier slides19:03
SumitNaiksatam#action SumitNaiksatam to update presentation slides19:03
s3wongSumitNaiksatam: OK19:03
SumitNaiksatams3wong: thanks for the reminder!19:03
SumitNaiksatamalright, lets call it a wrap (we can continue the discussion in #openstack-gbp)19:04
SumitNaiksatamthanks all for joining19:04
SumitNaiksatambye19:04
SumitNaiksatam#endmeeting19:04
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"19:04
openstackMeeting ended Thu Oct  9 19:04:30 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:04
openstackMinutes:        http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-10-09-18.01.html19:04
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-10-09-18.01.txt19:04
openstackLog:            http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-10-09-18.01.log.html19:04
ivar-lazzarobye19:04
rkukurabye19:04
s3wongbye (lunch-time)19:04
*** bpokorny has quit IRC19:05
*** glebo has left #openstack-meeting-319:07
*** mwagner_lap has quit IRC19:08
*** BrianB_ has quit IRC19:09
*** jcoufal has joined #openstack-meeting-319:10
*** LouisF has quit IRC19:12
*** lhcheng has joined #openstack-meeting-319:15
*** jacalcat has joined #openstack-meeting-319:18
*** carl_baldwin has quit IRC19:19
*** hemanthravi has quit IRC19:21
*** cbader has quit IRC19:22
*** seizadi has joined #openstack-meeting-319:25
*** carl_baldwin has joined #openstack-meeting-319:26
*** hemanthravi has joined #openstack-meeting-319:30
*** jacalcat has left #openstack-meeting-319:41
*** david-lyle is now known as david-lyle_afk19:47
*** yyywu has quit IRC19:47
*** lhcheng has quit IRC19:48
*** lhcheng has joined #openstack-meeting-319:48
*** seizadi has quit IRC19:51
*** pettori has quit IRC19:52
*** MaxV has joined #openstack-meeting-319:53
*** lhcheng has quit IRC19:53
*** sigmavirus24 has left #openstack-meeting-319:54
*** ivar-laz_ has joined #openstack-meeting-319:55
*** Longgeek has quit IRC19:55
*** ivar-lazzaro has quit IRC19:57
*** hemanthravi has quit IRC20:05
*** jcoufal has quit IRC20:13
*** ivar-laz_ has quit IRC20:15
*** jacalcat has joined #openstack-meeting-320:22
*** matrohon has joined #openstack-meeting-320:25
*** lhcheng has joined #openstack-meeting-320:26
*** pettori has joined #openstack-meeting-320:30
*** otherwiseguy has quit IRC20:34
*** alexpilotti has quit IRC20:35
*** lhcheng has quit IRC20:38
*** lhcheng has joined #openstack-meeting-320:38
*** lhcheng has quit IRC20:43
*** david-lyle_afk is now known as david-lyle20:53
*** seizadi has joined #openstack-meeting-320:54
*** jcoufal has joined #openstack-meeting-320:58
*** alexsyip has joined #openstack-meeting-320:58
*** carl_baldwin has quit IRC21:02
*** jacalcat has left #openstack-meeting-321:02
*** otherwiseguy has joined #openstack-meeting-321:04
*** julim has quit IRC21:04
*** markmcclain has quit IRC21:05
*** jacalcat1 has joined #openstack-meeting-321:06
*** bpokorny has joined #openstack-meeting-321:07
*** bpokorny_ has quit IRC21:09
*** carl_baldwin has joined #openstack-meeting-321:11
*** ttrifonov is now known as ttrifonov_zZzz21:13
*** ivar-lazzaro has joined #openstack-meeting-321:14
*** HenryG has quit IRC21:14
*** jgrimm is now known as zz_jgrimm21:17
*** lhcheng has joined #openstack-meeting-321:20
*** jcoufal has quit IRC21:29
*** mfer has quit IRC21:32
*** matrohon has quit IRC21:33
*** lhcheng has quit IRC21:36
*** lhcheng has joined #openstack-meeting-321:36
*** dboik has quit IRC21:40
*** lhcheng has quit IRC21:41
*** jacalcat1 has left #openstack-meeting-321:41
*** pettori has quit IRC21:44
*** otherwiseguy has quit IRC21:49
*** Swami has quit IRC22:04
*** bpokorny_ has joined #openstack-meeting-322:04
*** jacalcat has joined #openstack-meeting-322:04
*** cathy_ has quit IRC22:05
*** jacalcat has left #openstack-meeting-322:05
*** bpokorny has quit IRC22:07
*** Sukhdev has joined #openstack-meeting-322:09
*** dboik has joined #openstack-meeting-322:25
*** MaxV has quit IRC22:38
*** peristeri has quit IRC22:39
*** shwetaap has quit IRC22:40
*** shwetaap has joined #openstack-meeting-322:41
*** Rajeev has quit IRC22:41
*** shwetaap has quit IRC22:45
*** ttrifonov_zZzz is now known as ttrifonov22:57
*** thangp has quit IRC22:58
*** HenryG has joined #openstack-meeting-323:07
*** MaxV has joined #openstack-meeting-323:09
*** MaxV has quit IRC23:13
*** igordcard has quit IRC23:16
*** bpokorny has joined #openstack-meeting-323:22
*** bpokorny_ has quit IRC23:24
*** flaper87 is now known as flaper87|afk23:25
*** bpokorny_ has joined #openstack-meeting-323:31
*** bpokorny has quit IRC23:34
*** hurgleburgler has quit IRC23:36
*** david-lyle has quit IRC23:40
*** zz_jgrimm is now known as jgrimm23:43
*** carl_baldwin has quit IRC23:46

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!