Thursday, 2014-03-13

*** david_lyle_ has quit IRC00:00
*** markmcclain has quit IRC00:04
*** lblanchard has quit IRC00:05
*** SumitNaiksatam has quit IRC00:11
*** SumitNaiksatam has joined #openstack-meeting-300:19
*** wchrisj has quit IRC00:37
*** devlaps1 has quit IRC00:37
*** sarob has joined #openstack-meeting-300:49
*** dolphm has quit IRC00:49
*** cjellick has quit IRC00:50
*** wchrisj has joined #openstack-meeting-300:51
*** sarob has quit IRC00:53
*** dolphm has joined #openstack-meeting-300:54
*** wchrisj has quit IRC00:56
*** julim has quit IRC00:56
*** wchrisj has joined #openstack-meeting-301:00
*** wchrisj has quit IRC01:12
*** wchrisj has joined #openstack-meeting-301:18
*** fungi has quit IRC01:29
*** banix has joined #openstack-meeting-301:36
*** wchrisj has quit IRC01:36
*** wchrisj has joined #openstack-meeting-301:43
*** alexpilotti has quit IRC01:43
*** sarob has joined #openstack-meeting-301:50
*** sarob has quit IRC01:56
*** wchrisj has quit IRC02:01
*** wchrisj has joined #openstack-meeting-302:11
*** mwagner_lap has joined #openstack-meeting-302:46
*** sarob has joined #openstack-meeting-302:53
*** xianghui has joined #openstack-meeting-302:54
*** sarob has quit IRC02:56
*** sarob has joined #openstack-meeting-302:57
*** jthopkin has joined #openstack-meeting-302:57
*** dguitarbite has joined #openstack-meeting-302:58
*** sarob__ has joined #openstack-meeting-302:58
*** sarob has quit IRC03:01
*** sarob__ has quit IRC03:05
*** sarob has joined #openstack-meeting-303:06
*** sarob has quit IRC03:10
*** jthopkin has quit IRC03:13
*** sarob has joined #openstack-meeting-303:16
*** fungi has joined #openstack-meeting-303:32
*** sarob has quit IRC03:46
*** MaxV has joined #openstack-meeting-303:46
*** sarob has joined #openstack-meeting-303:46
*** wchrisj has quit IRC03:48
*** MaxV has quit IRC03:50
*** sarob has quit IRC03:51
*** banix has quit IRC03:53
*** dguitarbite has quit IRC03:58
*** wchrisj has joined #openstack-meeting-304:00
*** banix has joined #openstack-meeting-304:03
*** dguitarbite has joined #openstack-meeting-304:04
*** eghobo has joined #openstack-meeting-304:26
*** wchrisj has quit IRC04:33
*** sarob has joined #openstack-meeting-304:47
*** banix has quit IRC04:49
*** sarob has quit IRC04:53
*** xianghui has quit IRC05:00
*** amotoki has joined #openstack-meeting-305:06
*** SumitNaiksatam has quit IRC05:07
*** SumitNaiksatam has joined #openstack-meeting-305:10
*** xianghui has joined #openstack-meeting-305:17
*** tmazur has joined #openstack-meeting-305:36
*** sarob has joined #openstack-meeting-305:50
*** sarob has quit IRC05:54
*** david-lyle has joined #openstack-meeting-305:57
*** david-lyle has quit IRC06:02
*** yamahata has quit IRC06:21
*** eghobo has quit IRC06:41
*** MaxV has joined #openstack-meeting-306:48
*** sarob has joined #openstack-meeting-306:51
*** MaxV has quit IRC06:53
*** sarob has quit IRC06:56
*** sarob has joined #openstack-meeting-307:01
*** sarob has quit IRC07:05
*** mrunge has joined #openstack-meeting-307:31
*** MaxV has joined #openstack-meeting-307:31
*** jtomasek has quit IRC07:32
*** jcoufal has joined #openstack-meeting-307:47
*** sarob has joined #openstack-meeting-307:54
*** d0ugal has joined #openstack-meeting-307:58
*** d0ugal has quit IRC07:58
*** d0ugal has joined #openstack-meeting-307:58
*** sarob has quit IRC07:58
*** MaxV has quit IRC08:09
*** tmazur has quit IRC08:09
*** saju_m has joined #openstack-meeting-308:12
*** ttrifonov_zZzz is now known as ttrifonov08:18
*** MaxV has joined #openstack-meeting-308:41
*** nacim has joined #openstack-meeting-308:44
*** sarob has joined #openstack-meeting-308:55
*** sarob has quit IRC09:02
*** jrist has quit IRC09:11
*** johnthetubaguy has joined #openstack-meeting-309:24
*** jrist has joined #openstack-meeting-309:24
*** lucian1 has joined #openstack-meeting-309:27
*** sarob has joined #openstack-meeting-309:58
*** jtomasek has joined #openstack-meeting-310:00
*** sarob has quit IRC10:02
*** mwagner_lap has quit IRC10:52
*** sarob has joined #openstack-meeting-310:59
*** sarob has quit IRC11:05
*** johnthetubaguy is now known as johnthebpguy11:15
*** lblanchard has joined #openstack-meeting-312:01
*** sarob has joined #openstack-meeting-312:02
*** sarob has quit IRC12:06
*** johnthetubaguy has joined #openstack-meeting-312:08
*** johnthebpguy has quit IRC12:09
*** jpomero has quit IRC12:09
*** xianghui has quit IRC12:26
*** jcoufal has quit IRC12:50
*** jcoufal has joined #openstack-meeting-312:51
*** sarob has joined #openstack-meeting-313:03
*** yamahata has joined #openstack-meeting-313:03
*** sarob has quit IRC13:08
*** dguitarbite has quit IRC13:11
*** julim has joined #openstack-meeting-313:17
*** mfer has joined #openstack-meeting-313:26
*** peristeri has joined #openstack-meeting-313:42
*** banix has joined #openstack-meeting-313:44
*** wchrisj has joined #openstack-meeting-313:57
*** ttrifonov is now known as ttrifonov_zZzz13:58
*** nextone92 has joined #openstack-meeting-314:06
*** sarob has joined #openstack-meeting-314:06
*** jthopkin has joined #openstack-meeting-314:07
*** amotoki has quit IRC14:09
*** sarob has quit IRC14:10
*** safchain has joined #openstack-meeting-314:12
*** nextone92 has quit IRC14:12
*** markmcclain has joined #openstack-meeting-314:17
*** markmcclain has quit IRC14:17
*** markmcclain has joined #openstack-meeting-314:19
*** saju_m has quit IRC14:22
*** xianghui has joined #openstack-meeting-314:31
*** xianghui has quit IRC14:33
*** xianghui has joined #openstack-meeting-314:36
*** carl_baldwin has joined #openstack-meeting-314:47
*** johnthetubaguy1 has joined #openstack-meeting-314:52
*** johnthetubaguy1 has quit IRC14:53
*** johnthetubaguy1 has joined #openstack-meeting-314:53
*** rossella_ has joined #openstack-meeting-314:53
*** xianghui has quit IRC14:55
*** ajo has joined #openstack-meeting-314:55
ajohi carl_baldwin  ;)14:55
carl_baldwinajo: Greetings14:56
*** xianghui has joined #openstack-meeting-314:56
*** rook has joined #openstack-meeting-314:58
ajohi rook ;)14:58
rookajo hey! thanks for the heads up14:58
carl_baldwinWell, let's get started.15:00
carl_baldwin#startmeeting neutron_l315:00
openstackMeeting started Thu Mar 13 15:00:20 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:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
*** openstack changes topic to " (Meeting topic: neutron_l3)"15:00
openstackThe meeting name has been set to 'neutron_l3'15:00
carl_baldwin#topic Announcements15:00
*** openstack changes topic to "Announcements (Meeting topic: neutron_l3)"15:00
carl_baldwin#link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam15:00
*** Sudhakar_ has joined #openstack-meeting-315:00
carl_baldwinFirst, I didn’t plan for daylight savings time when I chose the time for this meeting.15:01
carl_baldwinThe time shift has caused a bit of a problem for me.15:01
carl_baldwinI'd like to suggest a couple of possible meeting times.  Both Thursday.15:01
carl_baldwinThe first is an hour earlier.  I know that makes things very early for a few in Western US.15:02
ajoFor me it's actually better , +115:02
*** julim has quit IRC15:02
carl_baldwinThe second is two hours later which could be difficult for others in other parts of the world.15:02
safchainfor me both are ok15:03
*** julim has joined #openstack-meeting-315:03
safchainHI all btw15:03
carl_baldwinsafchain: hi15:03
ajosafchain, hi :)15:03
*** ywu has joined #openstack-meeting-315:04
carl_baldwinI'll wait a few days for others who might be reading the meeting logs to chime email.  Ping me on irc or email with any concerns.  I'll announce the meeting time before next week.  And, I'll consider the next shift in daylight savings time.  ;)15:04
ajosure, thanks carl_baldwin15:05
carl_baldwin#topic l3-high-availability15:05
*** openstack changes topic to "l3-high-availability (Meeting topic: neutron_l3)"15:05
carl_baldwinsafchain: Anything to report?15:05
*** johnthetubaguy has quit IRC15:05
safchaincurrently I'm working on the conntrackd integration,15:05
safchainThe assaf's patch has to be reworked a bit to support multicast15:06
carl_baldwinI need to review again.  Anything new on the FFE?  I fear that it didn't happen.15:07
*** sarob has joined #openstack-meeting-315:07
safchainI don't know if all of you have tested patches15:07
safchaincarl_baldwin, no new for FFE15:07
*** mwagner_lap has joined #openstack-meeting-315:07
*** cjellick has joined #openstack-meeting-315:07
*** pcm_ has joined #openstack-meeting-315:08
ajoI couldn't test yet safchain, but I will try to allocate some time for it.15:08
carl_baldwinOkay.  The sub team page has links and information about reviewing and testing but I'll admit I've not yet tested.15:08
*** cjellick has quit IRC15:08
safchaincarl_baldwin, I think this is almost everything for me, just need more feed back with functionnal test15:08
*** cjellick has joined #openstack-meeting-315:09
ajosafchain, do you have some functional test examples?15:09
ajoI could get some people on our team to provide feedback on that.15:09
carl_baldwinOkay, I am looking forward to running it.  I need a multi host development setup soon anyway.15:09
carl_baldwin#link https://docs.google.com/document/d/1P2OnlKAGMeSZTbGENNAKOse6B2TRXJ8keUMVvtUCUSM/edit#15:09
safchainajo, I will add some test use cases on the doc.15:10
carl_baldwinajo: ^ This is the doc.15:10
*** SumitNaiksatam has quit IRC15:10
ajoThanks, I mean, if we have already some kind of initial functional test written for this. I will keep a link to this doc for manual testing.15:11
safchainajo, not yet15:11
ajook, it's not easy15:11
safchainajo, but tempest test should works with HA enabled15:12
ajook, that's a good start15:12
*** sarob has quit IRC15:12
carl_baldwinsafchain: anything else?15:12
*** YorikSar has joined #openstack-meeting-315:13
safchainIt's ok for me15:13
carl_baldwin#topic neutron-ovs-dvr15:13
*** openstack changes topic to "neutron-ovs-dvr (Meeting topic: neutron_l3)"15:13
carl_baldwinDoesn't look like Swami is around.15:14
carl_baldwinSwami is still working on detailing changes to L3.15:14
carl_baldwinThe doc for L2 is up.  Could use more review.15:14
carl_baldwin#link  https://docs.google.com/document/d/1depasJSnGZPOnRLxEC_PYsVLcGVFXZLqP52RFTe21BE/edit#heading=h.5w7clq272tji15:14
safchainSure, I plan to review it by the end of the week15:15
carl_baldwinAlso looking in to integrating the HA L3 and HA DHCP was discussed.15:15
carl_baldwinsafchain: great15:16
Sudhakar_hi all...15:16
ajohi Sudhakar_15:17
carl_baldwinSudhakar_: hi15:17
safchaincarl_baldwin, yes I'll try to ping swami after reviewing the doc15:17
Sudhakar_carl_baldwin, is there a doc about HA DHCP?15:17
safchainhi Sudhakar_15:17
Sudhakar_hi ajo...15:17
carl_baldwinSudhakar_: I don't think there is a doc yet about it.  Only some initial discussion expressing interest in starting that work.15:17
Sudhakar_hi carl15:17
Sudhakar_Did Swami initiate the discussion?15:18
carl_baldwinSudhakar_: yes15:18
Sudhakar_Ok. I have some context then..15:18
Sudhakar_I am Swami's colleague ..based out of India15:18
Sudhakar_basically we were thinking of an Agent monitoring service....which can be used to monitor different agents ...15:19
Sudhakar_typically useful for L3 and DHCP when we have multiple NNs15:19
ajoSudhakar_, something like rpcdaemon ?15:20
Sudhakar_not exactly..15:20
Sudhakar_a thread which can started from plugin itself...15:20
Sudhakar_and act based on the agent report_states...15:20
*** mrunge has quit IRC15:21
ajoSudhakar_, what kind of actions?15:21
Sudhakar_for ex: if a DHCP agent hosting a particular network goes down ....and we have another active DHCP agent in the cloud...15:22
Sudhakar_agent monitor detects that this DHCP agent went down and trigger rescheduling the network's DHCP on to the other agent..15:22
ajoA few weeks ago, I was proposing that daemon agents could provide status via status file -> init.d "status", but it could be complementary.15:22
ajoaha, it makes sense Sudhakar_15:23
Sudhakar_currently we have agent_down_time configuration which will help us decide on rescheduling...15:23
carl_baldwinSudhakar_: Do you have any document describing this that we could review offline?15:23
Sudhakar_we could have another parameter altogether to avoid mixing up..15:23
safchainSudhakar_, It seems there is something like that for LBaaS15:23
ajoyes, a document on those ideas would be interesting,15:23
Sudhakar_we are refining the doc... will publish it for review soon..15:23
carl_baldwinActually, I made a mistake above.  I said HA DHCP where I should have said, more precisely, distributed DHCP.15:24
carl_baldwinSudhakar_: Great.15:24
ajoaha carl_baldwin , the one based in openflow rules?15:24
Sudhakar_Ok ..:)15:24
Sudhakar_Distributed DHCP was another thought...but i don't have much idea on that yet...15:25
carl_baldwinajo: open flow rules could play a part but that did not come up explicitly.15:25
ajounderstood15:25
carl_baldwin#topic l3-agent-consolidation15:26
*** openstack changes topic to "l3-agent-consolidation (Meeting topic: neutron_l3)"15:26
*** SumitNaiksatam has joined #openstack-meeting-315:26
carl_baldwinThis work is up for review but the bp was pushed out to Icehouse.15:26
carl_baldwinyamahata: anything to add?15:26
yamahatacarl_baldwin: nothing new this week.15:27
carl_baldwin#topic bgp-dynamic-routing15:27
*** openstack changes topic to "bgp-dynamic-routing (Meeting topic: neutron_l3)"15:27
carl_baldwin#link https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing15:27
carl_baldwin#link https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-mpls-vpn15:27
carl_baldwinnextone92: are you around?15:28
*** sarob has joined #openstack-meeting-315:28
carl_baldwinI spent some time reviewing the bgp-mpls bp this week and made some notes.15:28
carl_baldwinIt looks like a few key people aren't around this week to discuss.  So, I'll try again next week.15:29
carl_baldwin#topic DNS lookup of instances15:30
*** openstack changes topic to "DNS lookup of instances (Meeting topic: neutron_l3)"15:30
*** markmcclain has quit IRC15:30
carl_baldwinReally quick, I’m almost done writing a blueprint for this.  Then, I need get it reviewed internally before I can post it.15:30
carl_baldwinI hope to have more to report on this next week.15:30
ajosounds interesting, thanks carl_baldwin15:30
carl_baldwin#topic Agent Performance with Wrapper Overhead15:30
*** openstack changes topic to "Agent Performance with Wrapper Overhead (Meeting topic: neutron_l3)"15:30
carl_baldwin#link https://etherpad.openstack.org/p/neutron-agent-exec-performance15:31
carl_baldwinThis has come up on the ML this week.  I have worked on it some so I created this etherpad.15:31
rossella_carl_baldwin: nice summary on the etherpad15:32
ajoyes, thanks carl_baldwin  :)15:32
*** nextone92 has joined #openstack-meeting-315:32
carl_baldwinrossella_: ajo: thanks15:32
carl_baldwinSo, there are a number of potential ways to tackle the problem.15:32
carl_baldwinI'm wondering what could be done for Icehouse.15:33
nextone92carl_baldwin - sorry I'm so late to join the meeting15:33
*** Swami has joined #openstack-meeting-315:34
Sudhakar_carl_baldwin, thanks for putting up the doc. looking forward on this..15:34
ajoYes, I had that thought too carl_baldwin15:34
rossella_Icehouse is now15:34
rossella_we can't do much15:34
SwamiCarl: Sorry I am late today15:34
safchainyes, I will have a look to this etherpad15:34
carl_baldwinSwami: nextone92: Hi15:34
SwamiCarl: hi15:34
ajoYuriy's idea (priviledged agent) doesn't look bad from the point of view of keeping all in python. But looks like it requires more changes into neutron. Too bad to be at the end of the cycle.15:35
carl_baldwinrossella_: I fear you are right.  There isn't much unless we can find bugs that could be fixed in short order.15:35
YorikSaro/15:35
YorikSarI'm that Yuriy.15:35
*** jcoufal has quit IRC15:35
ajoHo YorikSar ! :)15:35
ajoHi :)15:35
YorikSarI don't think it'll become very intrusive15:35
carl_baldwinajo: YorikSar: My thinking is similar.  It may be a very good long term solution.15:35
carl_baldwinYorikSar: I noticed your additions to the ether pad only this morning so I have not had a chance to review them.15:36
YorikSarWe basically need to replace execute() calls with smth like rootwrap.client.execute()15:36
ajoI'm just worried with, for example, memory consumtion. We must keep all instances tied tight... to avoid leaking "agents"15:36
YorikSarajo: They can kill themselves by timeout.15:37
YorikSarThen we won;t leak them.15:37
ajoAnd at client exit15:37
ajoMay be, for ones running inside a netns: kill by timeout15:37
YorikSarajo: Yeah. Which can end up basically the same.15:37
ajothe system-wide ones: kill by client exit + longer timoeut15:38
ajocarl_baldwin, do you think this approach could have the potential to be backported to Icehouse if it's tackled from now to the start of Juno?15:38
*** lblanchard has quit IRC15:39
YorikSarajo: I'm thinking about trying to push this to oslo.rootwrap, actually. So backporting will be minimal, but it'll be another feature.15:40
carl_baldwinajo: I don't think it adds features and it wouldn't change the database.  So, I think there might be hope for it.15:40
ajocarl_baldwin, do we have a bug filed for this?15:40
carl_baldwin... not a new feature from the user perspective.  More of an implementation detail.15:40
ajoYes, we're killing a cpu-eating-bug....15:41
YorikSarcarl_baldwin: Oh, yes. Agree.15:41
carl_baldwinIt is a significant implementation detail though.15:41
ajoyes, I agree carl_baldwin15:41
carl_baldwinI don't think there is one overarching bug for this.15:42
carl_baldwinI have filed detailed bugs for some of the individual problems that I've found and fixed.15:42
ajocarl_baldwin, I can fill a bug with the details15:42
carl_baldwinajo: Great.15:42
ajo(basically, the start of the latest mail thread)15:42
ajo#action fill bug about the rootwrap overhead problem.15:43
ajois it done this way?15:43
ajosorry, I'm almost new to meetings15:43
haleybcarl_baldwin: perhaps for icehouse all we can do is continue chipping away at unnecessary calls, and maybe get your priority change in?  my $.0215:44
carl_baldwinajo: I think you need to mention your handle after action.  But, yes.  Everyone should feel free to add their own action items.15:44
ajo#action ajo fill bug about the rootwrap overhead problem.15:44
*** david-lyle has joined #openstack-meeting-315:44
Swamiis that even possible for icehouse, at this time15:44
rossella_haleyb: +115:44
YorikSarI'm going to work on POC for that agent soon, btw.15:44
carl_baldwinhaleyb: Yes.  I'm hoping to wrap up that priority change this week as a bug fix.15:45
YorikSarIt's going to be interesting stuff to code :)15:45
*** jpomero has joined #openstack-meeting-315:45
ajomay be, for icehouse, I could try to spend some time in reducing the python subset in the current rootwrap, and get a C++ translation we can use.15:45
carl_baldwinSwami: I imagine there is little that can be done for Icehouse.  Only bug fixes and I imagine that significant changes will not be accepted.15:45
SwamiYes that's my thought as well.15:46
ajo(automated one), but I'm unsure about the auditability of such solution. that might require some investigation.15:46
carl_baldwinajo: It might be worth a try.  That is something I'm not very familiar with though.15:46
ajocarl_baldwin: may be it's not much work <1 week, I could try to allocate the time for that with my manager...15:47
ajoI have found speed improvements of >x50 with the C++ translation, but the python subset is rather reduced.15:47
carl_baldwinajo: Remember that we need to reduce start up time and not necessarily execution speed.15:48
ajoYes, that's greatly reduced, let me look for some numbers I had.15:48
*** eghobo has joined #openstack-meeting-315:48
carl_baldwinajo: sounds good.15:48
carl_baldwinThere are updates to "sudo" and "ip" that can help at scale.  These fall outside the scope of the Openstack release.15:48
YorikSarI wouldn't actually call switching to some subset of Python staying with Python. it'd still be some other language.15:49
carl_baldwinIs there any documentation existing in openstack about tuning at the OS level?15:49
YorikSarBut it might worth it to compare our approaches and probably come up with some benchmark.15:49
ajo1 sec. getting the numbers15:49
carl_baldwinIf so, I thought we could add some information from the ether pad to that document.  If not, it could be created.15:50
mwagner_lapcarl_baldwin, not sure if there any docs on tuning at the OS level15:50
ajohttp://fpaste.org/85068/25818139/15:50
mwagner_lapassuming you are talking about the neutron server itself15:50
ajo[majopela@redcylon ~]$ time python test.py15:50
*** cjellick_ has joined #openstack-meeting-315:50
ajoreal0m0.094s15:50
ajo[majopela@redcylon ~]$ time ./test15:50
ajoreal0m0.004s15:50
carl_baldwin#action carl_baldwin will look for OS level tuning documentation and either augment it or create it.15:51
ajocarl_baldwin, there is an "iproute" patch, and a "sudo" patch, could you add them to the etherpad?15:52
carl_baldwinFWIW, my efforts at consolidating system calls to run multiple calls under a single wrapper invocation have shown that it is extremely challenging with little reward.15:52
carl_baldwinajo: I believe those patches are referenced from the etherpad.15:53
ajoah, thanks carl_baldwin15:53
ajoyou're right , [3] and [2]15:53
carl_baldwinajo: Some of them are rather indirect.  I'll fix that.15:53
carl_baldwin#action carl_baldwin will fix references to patches to make them easier to spot and follow.15:54
*** cjellick has quit IRC15:54
ajocarl_baldwin, doing it as we talk, :)15:54
carl_baldwinajo: cool, thanks.15:54
carl_baldwinSo, ajo and YorikSar We'll be looking forward to seeing what you come up with.  Keep the ether pad up and we'll collaborate there.15:56
*** alexpilotti has joined #openstack-meeting-315:56
YorikSarok15:56
carl_baldwinAnything else?15:56
carl_baldwin#topic General Discussion15:57
*** openstack changes topic to "General Discussion (Meeting topic: neutron_l3)"15:57
*** xianghui has quit IRC15:57
ajocarl_baldwin,15:57
ajoI've seen neighbour table overflow messages from kernel,15:58
ajowhen I start lots of networks,15:58
ajohave you seen this before?15:58
ajolots (>100)15:58
safchainajo, which plugin/agent ?15:58
haleybipv6 error?  i think we've seen that too15:58
ajonormal neutron-l3-agent15:58
ajowith ipv415:58
*** cjellick has joined #openstack-meeting-315:59
ajoand openvswitch15:59
carl_baldwinI believe that we have seen it but I did not work on that issue directly.  So, I cannot offer the solution.15:59
*** johnthetubaguy has joined #openstack-meeting-315:59
ajoIt's in my todo list15:59
ajoI tried to tune the ARP garbage collection settings on the kernel15:59
*** cjellick_ has quit IRC16:00
ajobut, I'm not sure if it's namespace related16:00
*** johnthetubaguy1 has quit IRC16:00
*** johnthetubaguy has quit IRC16:00
haleybajo: found my notes - yes, found and solution is to increase size - gc_thresh*16:00
carl_baldwinI've got a hard stop at the hour.  Feel free to continue discussion in the neutron room or here if no one has this room.16:00
carl_baldwinThank you all who came and participated.16:00
safchainthx carl_baldwin16:01
haleybajo: neighbor table is shared between all namespaces16:01
carl_baldwinPlease review the meetings logs and get back to me about potential time change for this meeting.16:01
Sudhakar_thanks carl16:01
carl_baldwinBye!16:01
carl_baldwin#endmeeting16:01
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"16:01
openstackMeeting ended Thu Mar 13 16:01:23 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/neutron_l3/2014/neutron_l3.2014-03-13-15.00.html16:01
nextone92thanks!16:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/neutron_l3/2014/neutron_l3.2014-03-13-15.00.txt16:01
openstackLog:            http://eavesdrop.openstack.org/meetings/neutron_l3/2014/neutron_l3.2014-03-13-15.00.log.html16:01
Swamithanks carl, bye16:01
*** Sudhakar_ has left #openstack-meeting-316:01
*** nextone92 has left #openstack-meeting-316:01
ajoaha haleyb yes, I've been working with the same, but still getting ARP errors,16:01
ajoI will investigate in more detail :)16:02
ajoThanks carl_baldwin16:02
ajobye everybody :)16:02
haleybdouble values, then keep going until they go away :)16:02
ajohehe :)16:02
rossella_bye16:02
ajothanks haleyb , I'll try it16:02
*** johnthetubaguy has joined #openstack-meeting-316:02
*** jcoufal-mobile has joined #openstack-meeting-316:03
*** Swami has left #openstack-meeting-316:05
*** rossella_ has left #openstack-meeting-316:06
*** cnesa has joined #openstack-meeting-316:07
*** markmcclain has joined #openstack-meeting-316:08
*** cjellick has quit IRC16:09
*** YorikSar has left #openstack-meeting-316:10
*** pcm_ has left #openstack-meeting-316:10
*** cjellick has joined #openstack-meeting-316:13
*** cjellick has quit IRC16:14
*** cjellick has joined #openstack-meeting-316:14
*** johnthetubaguy has quit IRC16:16
*** johnthetubaguy has joined #openstack-meeting-316:16
*** jcoufal-mobile has quit IRC16:17
*** jcoufal-mobile has joined #openstack-meeting-316:18
*** devlaps has joined #openstack-meeting-316:19
*** cjellick_ has joined #openstack-meeting-316:22
*** sarob has quit IRC16:22
*** sarob has joined #openstack-meeting-316:23
*** cjellick has quit IRC16:23
*** sarob has quit IRC16:27
*** jcoufal-mobile_ has joined #openstack-meeting-316:28
*** jcoufal-mobile has quit IRC16:28
*** jcoufal-mobile_ has quit IRC16:28
*** jcoufal-mobile has joined #openstack-meeting-316:29
*** cjellick_ has quit IRC16:30
*** cjellick has joined #openstack-meeting-316:30
*** jthopkin has left #openstack-meeting-316:31
*** jcoufal-mobile_ has joined #openstack-meeting-316:31
*** jcoufal-mobile_ has quit IRC16:33
*** jcoufal-mobile has quit IRC16:33
*** sarob has joined #openstack-meeting-316:37
*** sarob has quit IRC16:42
*** lblanchard has joined #openstack-meeting-316:48
*** sarob has joined #openstack-meeting-316:53
*** jtomasek has quit IRC17:00
*** lpetrut has joined #openstack-meeting-317:01
*** beyounn has joined #openstack-meeting-317:02
*** lpetrut_ has joined #openstack-meeting-317:03
*** lpetrut has quit IRC17:05
*** freesoftware has joined #openstack-meeting-317:07
*** coasterz has joined #openstack-meeting-317:07
*** nacim has quit IRC17:14
*** kathmandude has joined #openstack-meeting-317:18
*** kathmandude has quit IRC17:23
*** sarob has quit IRC17:25
*** SridarK has joined #openstack-meeting-317:34
*** GlenTheN00b has joined #openstack-meeting-317:42
*** freesoftware has quit IRC17:42
*** MaxV has quit IRC17:42
*** kathmandude has joined #openstack-meeting-317:43
*** lpetrut_ has quit IRC17:43
*** kathmandude has quit IRC17:45
*** kevinbenton has joined #openstack-meeting-317:46
*** sarob has joined #openstack-meeting-317:48
*** jpomero has quit IRC17:56
*** hemanthravi has joined #openstack-meeting-317:57
*** s3wong has joined #openstack-meeting-318:00
SumitNaiksatamHi Neutron Folks! :-)18:00
s3wongHello SumitNaiksatam18:00
hemanthravihi sumit18:00
banixHi there18:00
SumitNaiksatams3wong: hemanthravi banix: hi18:01
beyounnhi18:01
banixhi s3wong18:01
SridarKHi18:01
s3wongbanix: hi18:01
*** pcm_ has joined #openstack-meeting-318:01
banixhi sumit18:01
*** jpomero has joined #openstack-meeting-318:01
*** mandeep has joined #openstack-meeting-318:02
*** prasadv has joined #openstack-meeting-318:02
*** SridharRamaswamy has joined #openstack-meeting-318:02
SumitNaiksatamlets wait a min for eugene18:02
pcm_hi18:02
mandeepSumitNaiksatam: hi18:02
SumitNaiksatampcm_: hi, thanks for joining18:02
SumitNaiksatammandeep: hi18:02
*** enikanorov_ has joined #openstack-meeting-318:02
pcm_SumitNaiksatam: glad to be here18:02
s3wongvery late for Eugene now18:02
prasadvsumitNaiksatam:hi18:02
SumitNaiksatamenikanorov_: hi18:02
enikanorov_hi folks18:02
SumitNaiksatamlets get started18:02
s3wongbut he is here :-)18:02
cgoncalveshi18:03
SumitNaiksatam#startmeeting Networking Advanced Services18:03
openstackMeeting started Thu Mar 13 18:03:10 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.18:03
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:03
*** openstack changes topic to " (Meeting topic: Networking Advanced Services)"18:03
openstackThe meeting name has been set to 'networking_advanced_services'18:03
*** OSM has joined #openstack-meeting-318:03
SumitNaiksatamI was pinged by a lot of folks during the past few days about the status of the general services' framework18:03
SumitNaiksatamand what went into Icehouse, and what remains to be done18:04
*** obondarev has joined #openstack-meeting-318:04
SumitNaiksatamhence I though it would be good for the various services' team to converge here18:04
SumitNaiksatamwe used to have this meeting before but we suspended it to support more pressing issues facing Neutron18:04
*** OSM is now known as songole18:04
SumitNaiksatamunfortunately we did not get much into Icehouse in terms of the services' framework18:05
*** GlenTheN00b has quit IRC18:05
SumitNaiksatammoreover we are also reconsidering some of the existing abstractions - namely service-types18:05
SumitNaiksatamlets get started with that18:05
SumitNaiksatam#topic Flavors Framework18:05
*** openstack changes topic to "Flavors Framework (Meeting topic: Networking Advanced Services)"18:05
SumitNaiksatam#link https://wiki.openstack.org/wiki/Neutron/FlavorFramework18:05
*** thinrichs has joined #openstack-meeting-318:06
SumitNaiksatamenikanorov_: put out the wiki and started a thread on the mailing list as well18:06
s3wongSumitNaiksatam: quickly skim through it this morning, it seems very abstract. It only adds a flavor type on top of existing service type and provider driver18:06
SumitNaiksatams3wong: okay18:06
enikanorov_s3wong: correct18:06
SumitNaiksatamso i see the following points that we probably need to consider (and then i will yield to enikanorov_)18:07
enikanorov_the idea is to choose provider based on service capabilities requirested by the user18:07
SumitNaiksatam1. the framework has to have generic application to Neutron services18:07
SumitNaiksatam2. it should provide for representation of different “flavors” of the same service18:07
SumitNaiksatam3. in terms of service matching we need to decide desire versus exact match semantics18:08
SumitNaiksatam4. and the name :-) ( we can punt this to the mailer)18:08
SumitNaiksatamenikanorov_: is that reasonable characterization of the discussion till date?18:08
enikanorov_yes, pretty much!18:08
pcm_enikanorov_: would like to hear more about how the flavor translate to a specific driver instance... fuzzy to me18:08
hemanthravidoes it allow for def of a new type of service along with associated params?18:09
pcm_maybe some concrete examples would help me (I'm dense :)18:09
*** sarob__ has joined #openstack-meeting-318:09
enikanorov_pcm: the flavor represends requirements (capabilities) that user wants from the service. some drivers support some caps, others don't18:09
*** kathmandude has joined #openstack-meeting-318:09
enikanorov_how capabilities are represented is yet to be defined18:09
enikanorov_initially I proposed quite free form of definition like {'parameter': allowed_values (or range)}18:10
pcm_enikanorov_: so, say for VPN, where may have multiple drivers that can all meet the need, how does one select a specific driver?18:10
enikanorov_as an alternative, flavor could be a set of tags18:10
*** sarob has quit IRC18:10
enikanorov_pcm_: via scheduling, it can be random, it can consider available appliances18:10
enikanorov_that is yet to be decided18:11
enikanorov_the proposal is that scheduler asks drivers for resources that match the flavor18:11
s3wongpcm_ : good point. Since the intention is to hide vendor name, that selection is very unpredictable18:11
enikanorov_and then choses the backedn depending on scheduling algorithm18:11
SumitNaiksatamenikanorov_: on the representation of capabilities, the base set of attributes can be abstract with the possibility to extend to specifics18:12
SridarKenikanorov_:  There could be a use case where one might want to pick a specific vendor implementation as perhaps this has been validated earlier18:12
SridarKshould this be considered ?18:12
SumitNaiksatamSridarK: my point ^^^18:12
enikanorov_SumitNaiksatam: to me it should be a part of Admin API, where admin can create flavors in relatively free form18:12
SumitNaiksatamincorporate base set of abstract attributes18:13
SumitNaiksatamenikanorov_: yes18:13
enikanorov_SumitNaiksatam: but also we need to be bw compatible, so I'm thinking about some default flavors, that drivers can export18:13
SumitNaiksatamand then allow for free form attributes as well, in case the admin wants to expose18:13
s3wongenikanorov_: admin can then specify vendor name into the available flavors then?18:13
SumitNaiksatamenikanorov_: yes, defaults can make it backward compatible18:13
enikanorov_SridarK: I think in this case that could be solved by the flavor that will be provider-specific18:13
SridarKok would we get into a proliferation of flavors18:14
enikanorov_s3wong: yes, like that, add 'provider' parameter to a flavor and it will map to a specific provider, for instance18:14
*** lenrow_ has joined #openstack-meeting-318:14
banixs3wong: that sounds like a reasonable option18:14
pcm_+1 ^^18:14
SridarKs3wong: +118:14
enikanorov_flavor workflow should definitely allow what is allowed with provider workflow18:14
s3wongyes, so now flavor definition is an provider API, and selection API is tenant API?18:15
SumitNaiksatamenikanorov_: to pcm_'s question we can also don't have to have exact match semantics18:15
enikanorov_yes, selection is tenant API18:15
SumitNaiksatams3wong: i believe so18:15
enikanorov_SumitNaiksatam: of course18:15
SumitNaiksatamenikanorov_: ok good we are on the same page18:16
banixSimilar to nova flavors I suppose18:16
SumitNaiksatamfolks, lets have some structure to the conversation here18:16
SumitNaiksatami think we are talking over each other18:16
SumitNaiksatamthis is a long topic of discussion, so we are not going to resolve things here18:16
SumitNaiksatamwe want to get the discussion started and get people thinking so that they can provide feedback18:16
SumitNaiksatamok so who's next?18:17
* pcm_ takes one step back :)18:17
*** Ly100 has joined #openstack-meeting-318:17
SumitNaiksatampcm_: i was going to say you asked the first question :-)18:17
*** MaxV has joined #openstack-meeting-318:17
SumitNaiksatampcm_: so far good?18:17
pcm_yes18:18
enikanorov_so the question I have18:18
SumitNaiksatamok hemanthravi next18:18
enikanorov_is about patches that integrate fwaas/vpn/l3 with provider framework18:18
SumitNaiksatamenikanorov_: sorry go ahead18:18
SumitNaiksatamenikanorov_: i don't think there is a plan to integrate those18:18
hemanthraviwas asking if flavors allows for a new type of service to be defined18:18
enikanorov_i think that those patches make sense even if we agree on flavors18:18
enikanorov_but with the exception18:18
SumitNaiksatamenikanorov_: the service type framework patches are on hold18:19
enikanorov_that provider should be exposet into the tenant API18:19
enikanorov_but rather be a read-only attribute18:19
SumitNaiksatamenikanorov_: ok, makes sense to me18:19
enikanorov_because it seems that we're still going to have mapping between resource and the driver18:19
s3wongenikanorov_: sounds good18:19
enikanorov_even if we have flavors18:19
pcm_enikanorov_: So set provider via flavor attriobute and allow showing through provider framework?18:20
SumitNaiksatamenikanorov_: i think if we can explain how the new abstraction (if we call it flavors), incorporates the provider, that will be helpful18:20
mandeepenikanorov_: SumitNaiksatam: There are similar needs in the group policy framework. And they too are creating artifacts for publishing and consuming services and having best match semantics. At appropriate time, should consider that as an alternative as well18:20
enikanorov_flavor is a scheduling hint where provider is dispatching hint18:20
SumitNaiksatammandeep: sure18:20
SridarKenikanorov_: could u pls clarify on the read only for tenant - meaning tenant cannot set a provider ?18:20
enikanorov_SridarK: yes, tenant can't set the provider - that's an idea of flavor framework18:20
SridarKthat is fine thanks enikanorov_:18:21
enikanorov_but we still need to bind resource to a provider, but not manually18:21
s3wongSridaK: one would imagine tenant can select from available options, but not creating one18:21
SridarKs3wong: Yes agreed18:21
banixSumitNaiksatam: Can you elaborate why service type patches  are on hold? just not enough time for review?18:21
pcm_banix: no, pending flavor discussion18:22
SumitNaiksatambanix: ostensibly because we are rethinking the service type framework18:22
SumitNaiksatamenikanorov_: hemanthravi's question was - "was asking if flavors allows for a new type of service to be defined"18:22
SumitNaiksatamhemanthravi: i believe the answer is yes18:23
banixand that is to generalize the framework, provide features such as not exact matches, etc18:23
enikanorov_not sure i get the question :)18:23
mandeepenikanorov_: At least in the policy framework discussion, it allows for both specific provider, or for it to be satisfied by "best match"18:23
hemanthravifor eg a service other than FW, VPN18:23
enikanorov_mainly because 'type of service' is a broad term18:23
SumitNaiksatamenikanorov_: so that question is applicable to service chains as well18:23
SumitNaiksatamenikanorov_: what if we want to expose a service chaing via the flavors framework18:23
SumitNaiksatamenikanorov_: this was the earlier plan with STF18:24
enikanorov_SumitNaiksatam: i think that's where tag representation of capabilities can help18:24
SumitNaiksatam*chain18:24
s3wongSumitNaiksatam: hemanthravi: the available service type in a flavor needs to be submitted via bp, I suppose. Instead of relying on flavor framework to allow everyone to freely add service type18:24
mandeepSumitNaiksatam: This _should_ apply to service chains as well. A service chain is yet another service18:24
enikanorov_you specify flavor={'type': 'chain_vpn_lbaas'} - something like that18:24
SumitNaiksatammandeep: thats what i would think18:24
enikanorov_(primitive example)18:24
banixs3wong: that won't work that nicely for service chains18:24
s3wongbanix: true, since those are dynamically created by tenants18:25
SumitNaiksatamenikanorov_: yeah something like that18:25
enikanorov_also, i'm not sure about ' freely add service type'18:25
enikanorov_in my understanding 'service type' is something that has code implementation18:25
banixbut I see discussion on limiting the capability for having arbitrarily constructed chains18:25
enikanorov_like now we have service plugins18:25
SridarKSumitNaiksatam: we will need to have a "set" of service drivers for each element in the chain18:25
enikanorov_so it's not something that admin or tenant defines18:25
*** johnthetubaguy has quit IRC18:26
SumitNaiksatambanix s3wong enikanorov_ so i think the point here is that this deployment specific18:26
s3wongenikanorov_: I guess the question is - should a service chain, defined by tenant, be a "service type"?18:26
enikanorov_s3wong: i think you're talking about chain implementation18:26
SumitNaiksatams3wong: the service chain is not necessarily a dynamic construct18:26
enikanorov_i think tenant can't specify chain template18:27
prasadvenikanorov_: since the framework is matching, it can match the service type to the driver by querying isnt it?18:27
*** johnthetubaguy has joined #openstack-meeting-318:27
banixenikanorov: and having a service type of type chain does not make sense? Just wondering if that could be an option18:27
SumitNaiksatams3wong: the particular deployment/provider has to support the service chain, and it will expose only those that it supports18:27
*** johnthetubaguy has quit IRC18:27
enikanorov_banix: 'chain' is too abstract. FW_lbaas_chain makes sense18:27
enikanorov_or other concrete chains18:28
SumitNaiksatamenikanorov_: yes18:28
enikanorov_but those are static18:28
enikanorov_that's how i see it18:28
SumitNaiksatamenikanorov_: that has been our approach all along18:28
enikanorov_static - means we, developers, define them18:28
s3wongSumitNaiksatam: in that case, the provider for such chain that provider can support has multiple drivers?18:28
enikanorov_SumitNaiksatam: yep18:28
SumitNaiksatams3wong: could have multiple drivers18:28
SumitNaiksatams3wong: they will probably be different chains18:29
SumitNaiksatams3wong: i can see that you are probably seeing an issue with combinatorial explosion18:29
SumitNaiksatams3wong:  however in reality that might not be the case18:29
s3wongSumitNaiksatam: absolutely18:29
banixI may be thinking too broadly for an implementation, but that sounds like a big limitation. But I have seen earlier discussion on this and see the thoughts on this issue.18:29
*** shamkut has joined #openstack-meeting-318:29
banixSumitNaiksatam: yes18:30
pcm_so the chain is specific to the provider right?18:30
SumitNaiksatampcm_: yes18:30
SumitNaiksatams3wong banix: so essentially you are expressing the need to chains created by users?18:30
SumitNaiksatam* need to create chains18:31
s3wongSumitNaiksatam: it is extremely limiting is a tenant cannot choose to chain together available services provided by provider18:31
s3wongs/is/if18:31
SumitNaiksatams3wong: ok18:31
SumitNaiksatamso we are half way into the meeting18:31
pcm_Would it be the case that the chain would always relate to one provider, or could we cross providers (does that even make sense)?18:31
SumitNaiksatami think this is a nice segue into the next part of the agenda18:31
banixSumitNaiksatam: Yes, and the ability to compose chains from other services that are defined by the provider18:31
*** lpetrut has joined #openstack-meeting-318:32
SumitNaiksatam#topic Service insertion/chaining18:32
*** openstack changes topic to "Service insertion/chaining (Meeting topic: Networking Advanced Services)"18:32
s3wongperfect point to move into the next topic :-)18:32
banixto wrap up the previous section, is it fait o say flavors are a generalized form of service types that we are agreeing on working towsrds?18:33
SumitNaiksatambtw, we are not done with the flavors discussion, but we have started to bleed into the complementary discussion (so thought we could make progress on the agenda :-))18:33
SumitNaiksatamenikanorov_: please stay with us :-)18:33
*** ftcjeff has joined #openstack-meeting-318:33
SumitNaiksatamok so coming back chaining18:33
enikanorov_i will, although in read-only mode mostly :)18:33
SridarKSumitNaiksatam: in terms of who defines the chain and who defines the provides in the simpler flavor case - seems we are saying diff things18:33
SumitNaiksatamfirst an update18:33
cgoncalvesSumitNaiksatam: I also share banix's opinion on allowing users to define chains18:33
SridarK*provider18:33
*** shamkut has quit IRC18:33
SumitNaiksatam#link https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering18:34
s3wonggo ahead SumitNaiksatam18:34
SumitNaiksatamagain due to the resource/time crunch we were left to target only a very tiny part of the above blueprint18:34
SumitNaiksatam#link #link https://review.openstack.org/#/c/6259918:35
SumitNaiksatamunfortunately, even that did not make it in!18:35
s3wongSumitNaiksatam: this is already out for Icehouse, correct?18:35
*** sarob__ has quit IRC18:35
SumitNaiksatamnot for lack of effort18:35
SumitNaiksatams3wong: nope, it was not granted FFE18:36
SumitNaiksatamanyway18:36
SumitNaiksatamso although it was a FWaaS related patch, the idea was to introduce the notion of a service context18:36
SumitNaiksatamservice context will aid in service insertion18:36
SumitNaiksatamthe service context can be one or a combination of a number of references to other neutron objects18:37
SumitNaiksatamvery simple and basic18:37
cgoncalvesSumitNaiksatam: would it be possible in the defined blueprint to allow vm instances to be part of a chain? use case: DPI is not supported in openstack as a service; one could create a vm instance with a DPI instance (e.g. ntop) and bind it to a chain FWaaS->VM_DPI->LbaaS18:38
SumitNaiksatamthe hope was that all services would implement the service context, and we could subsequently use it to build service chains18:38
SumitNaiksatamcgoncalves: yes18:38
SumitNaiksatamcgoncalves: its agnostic to the service implementation18:38
cgoncalvesSumitNaiksatam: awesome. thanks!18:39
s3wongSumitNaiksatam: what is the definition of service context?18:39
SumitNaiksatams3wong: its in the blueprint ;-)18:39
SumitNaiksatams3wong: service_context can be used by the user to convey the intent to the backend as to where to anchor the particular service instance18:40
banixMainly a reference to where a service can be inserted18:40
SumitNaiksatambanix: yeah, much more concise :-)18:41
s3wongbanix: I see. thanks. I also just found it in the document :-)18:41
SumitNaiksatams3wong: make sense?18:41
s3wongSumitNaiksatam: yes18:41
SumitNaiksatamokay18:41
SumitNaiksatamso moving on18:41
banixThat seems very logical to me but I think there were concerns wrt backward compability18:42
*** safchain has quit IRC18:42
banixwhich as far as I can see are not there18:42
SumitNaiksatambanix: actually those were not substantiated18:42
SumitNaiksatambanix: yeah18:42
kathmandudecan there be multiple service instances with different contexts?18:42
s3wongSumitNaiksatam: is ports Neutron ports or L4 port number?18:42
SumitNaiksatambanix: that was probably lack of understanding, default semantics can make it backward compatible18:42
banixyeah18:42
SumitNaiksatams3wong: all neutron constructs, so neutron port18:42
SumitNaiksatamkathmandude: yes18:43
SumitNaiksatamso perhaps these are too many topics for a short meeting18:44
banixSo service insertion context allows the insertion to be explicitly defined ….18:44
SumitNaiksatambanix: yes, but as supported by the backend provider18:44
banixthat's right18:44
SumitNaiksatambanix: there will be validation, and not all contexts will be valid for a service or deployment18:44
SumitNaiksatamso what i was going to say is I think we have planted enough seeds in this discussion, both on the flavors front and the service insertion/chaining18:45
banixyes18:45
SumitNaiksatamwe definitely need more discussion time18:45
s3wongSumitNaiksatam: so how to proceed beyond these seeds? :-)18:45
SumitNaiksatami want to give time to pcm_ as well for the next topic18:45
banixand probably a timetable for ourselves so we can move things forward18:46
SumitNaiksatams3wong: yes, lets summarize at the end of the meeting18:46
SumitNaiksatambanix: yes18:46
SumitNaiksatam#topic Vendor plugins for L3 services18:46
*** openstack changes topic to "Vendor plugins for L3 services (Meeting topic: Networking Advanced Services)"18:46
SumitNaiksatam#link http://lists.openstack.org/pipermail/openstack-dev/2014-February/026193.html18:46
SumitNaiksatampcm_: all yours :-)18:46
pcm_thanks18:46
pcm_pretty much was thinking about these topics:18:47
pcm_1) how to handle/lcoate vendor config files18:47
pcm_2) way to do vendor validation (e.g. validate, commit, apply ~ to precommit/postcommit)18:47
pcm_3) How to tell client what vendor capabilities are18:48
pcm_4) How to report to plugin status, when there are problems18:48
pcm_I've seen a bunch of these issues with VPN development and imagine other svcs do to.18:48
pcm_Should we setup a separate IRC to discuss some ideas on this?18:49
* pcm_ primarily wanted to get people thinking about it some18:49
SridarKpcm_: we also need the flavor discussion to mature to understand what base we are building on18:50
pcm_SridarK: agreed18:50
s3wongpcm_: agree with SridaK. Seems like a lot of these should be solved by flavors framework18:50
*** cnesa has quit IRC18:51
pcm_s3wong: not sure how flavors will handle some of the issues like #218:51
s3wongpcm_: #1 and #3 should18:51
SridarKs3wong: pcm_'s intent is more to see how vendors adopt a framework18:51
pcm_s3wong: agree18:52
pcm_For #2, for example, the plugin for VPN will validate, commit and then call service driver to handle18:52
pcm_that, unfortunately is too late for vendor to validate and prevent commit.18:52
pcm_would be nice for a common framework that all services use to allow for this.18:53
pcm_thinking hooks to pre/post commit actions, like done in ML2/L2 plugins18:53
banixsimilar to ML2 separation for mechanism drivers?18:53
s3wongpcm_ : plugin/driver has to be involved for #2, no escape for that one18:53
mandeepbanix: precisely. It looks like the same problem18:54
SridarKpcm_: if SumitNaiksatam: enikanorov_: are okay too - could this be a part of the flavors discussion at least initially18:54
* pcm_ need to read up on ML2 more :)18:54
SumitNaiksatamSridarK: not sure i got that18:55
pcm_SridarK: sure. There are likely parts that fit in nicely and some that maybe don't.18:55
SumitNaiksatamSridarK: but we can follow up18:55
enikanorov_that's an interesting point18:55
SumitNaiksatampcm_: sorry to cut you short, since only 5 mins, just want to plan for future meetings as well18:55
pcm_sure np18:55
enikanorov_basically right now the driver is able to put resource into ERROR state18:55
SumitNaiksatampcm_: we will continue the discussion in this forum18:55
enikanorov_that's all it can do18:55
SridarKSumitNaiksatam: since the flavors is also evolving - perhaps we need to get that model settled in first18:55
*** jpomero has quit IRC18:55
SumitNaiksatamSridarK: sure18:55
SumitNaiksatam#topic Summary and planning18:56
*** openstack changes topic to "Summary and planning (Meeting topic: Networking Advanced Services)"18:56
s3wongenikanorov_: seems like we need to extend flavor framework18:56
enikanorov_s3wong: how do you see it?18:56
SumitNaiksatamso i think there is a lot of discussion needed on a different topics18:56
SumitNaiksatamunfortunately time is short and we have too many meetings18:56
SumitNaiksatamso how does everyone feel about having this is as a biweekly meeting18:57
mandeepAnd make it 2 hrs ... we need that time18:57
pcm_SumitNaiksatam: sure, or weekly...18:57
enikanorov_i'm fine with that18:57
SridarKSumitNaiksatam:  From the chaos - with folks jumping over one other  (in a good way)  in the mtg -  only reflects the the intense need to solve this problem :-)18:57
mandeep(just to get to bottom of some of these discussions)18:57
enikanorov_i'm for weekly, but 1 hour long18:57
banixweekly seems what we need18:58
pcm_enikanorov_: +1 and just limit topic18:58
s3wongSumitNaiksatam: would be nice to make it NOT immediately before the group-policy meeting18:58
SumitNaiksatamenikanorov_: man deep's suggestion to make to 2 hour but biweekely>18:58
prasadvs3wong: +118:58
SumitNaiksatams3wong: sure18:58
enikanorov_2 hrs is exhausting18:58
mandeepOK18:58
hemanthravi+1 weekly, 1hr18:58
SumitNaiksatamif we keep it to only one topic, other topics will be delayed18:58
SumitNaiksatamalright, one hour weekly18:59
*** lenrow has joined #openstack-meeting-318:59
SumitNaiksatamwe can alternate topics18:59
pcm_es18:59
pcm_yes18:59
s3wongmove it back to wednesday, perhaps?18:59
mandeepThat will work too18:59
SridarK+118:59
SumitNaiksatamthere are other topics which we did not even touch18:59
SumitNaiksatamok18:59
SumitNaiksatammany others18:59
SumitNaiksatamregarding day/time?18:59
SumitNaiksatamwednesday?18:59
banixLets prioritize wrt what we need to get others onboard as well19:00
s3wongSumitNaiksatam: +1 for Wednesday19:00
SumitNaiksatam17:00 UTC?19:00
banixok with wednesday19:00
SumitNaiksatamthat is 10 AM PDT19:01
banixsounds good to me19:01
pcm_+119:01
s3wong+119:01
prasadv+119:01
SridarK+119:01
s3wonggood for enikanorov_?19:01
SumitNaiksatamenikanorov_: is always here :-P19:01
enikanorov_looks fine19:01
SumitNaiksatamok done for now - wedenesday 17:00 UTC19:02
SumitNaiksatamwe can adjust later19:02
banixtime to move to alt19:02
SumitNaiksatamyeah, next meeting is waiting19:02
s3wongTalk to you guys next week!19:02
banixi mean for policy call19:02
cgoncalvesbanix: indeex :)19:02
*** songole has quit IRC19:02
SumitNaiksatami had a summary ready, but not time19:02
pcm_thanks for hosting SumitNaiksatam19:02
SumitNaiksatamno19:02
cgoncalves*indee19:02
SumitNaiksatamok thanks everyone19:02
s3wongthanks!19:02
*** pcm_ has left #openstack-meeting-319:02
banixthank you sumit19:02
SumitNaiksatamwill send summary in email19:02
*** lenrow__ has joined #openstack-meeting-319:02
SridarKbye19:02
SumitNaiksatambanix: sure19:02
*** prasadv has left #openstack-meeting-319:02
SumitNaiksatam#endmeeting19:02
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"19:02
openstackMeeting ended Thu Mar 13 19:02:48 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:02
openstackMinutes:        http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-03-13-18.03.html19:02
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-03-13-18.03.txt19:02
openstackLog:            http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-03-13-18.03.log.html19:02
*** mandeep has left #openstack-meeting-319:02
*** lenrow_ has quit IRC19:05
*** Ly100 has quit IRC19:10
*** SridharRamaswamy has quit IRC19:19
*** mwagner_lap has quit IRC19:19
*** lenrow has quit IRC19:22
*** SridarK has quit IRC19:22
*** sarob has joined #openstack-meeting-319:27
*** peristeri has quit IRC19:29
*** kathmandude has left #openstack-meeting-319:32
*** devlaps has quit IRC19:38
*** devlaps has joined #openstack-meeting-319:39
*** sarob has quit IRC19:40
*** sarob has joined #openstack-meeting-319:41
*** sarob has quit IRC19:42
*** devlaps has quit IRC19:43
*** eghobo has quit IRC19:45
*** hemanthravi has quit IRC19:47
*** thinrichs has quit IRC19:47
*** s3wong has quit IRC19:49
*** beyounn has quit IRC19:51
*** jcoufal has joined #openstack-meeting-319:56
*** MaxV has quit IRC19:58
*** MaxV has joined #openstack-meeting-319:59
*** lblanchard has quit IRC20:03
*** devlaps has joined #openstack-meeting-320:09
*** jtomasek has joined #openstack-meeting-320:13
*** devlaps has quit IRC20:14
*** julim has quit IRC20:15
*** jcoufal has quit IRC20:16
*** eghobo has joined #openstack-meeting-320:35
*** eghobo has quit IRC20:40
*** eghobo has joined #openstack-meeting-320:44
*** eghobo has quit IRC20:47
*** eghobo has joined #openstack-meeting-320:47
*** cnesa has joined #openstack-meeting-320:50
*** sarob has joined #openstack-meeting-320:55
*** beyounn has joined #openstack-meeting-320:59
*** jthopkin has joined #openstack-meeting-321:03
*** lenrow__ has quit IRC21:03
*** lenrow has joined #openstack-meeting-321:04
*** devlaps has joined #openstack-meeting-321:10
*** devlaps has quit IRC21:11
*** devlaps1 has joined #openstack-meeting-321:11
*** cnesa2 has joined #openstack-meeting-321:15
*** cnesa has quit IRC21:16
*** safchain has joined #openstack-meeting-321:20
*** RajeshMohan has joined #openstack-meeting-321:20
*** banix has quit IRC21:21
*** sarob has quit IRC21:30
*** sarob has joined #openstack-meeting-321:31
*** markmcclain has quit IRC21:31
*** lpetrut has quit IRC21:43
*** sarob has quit IRC21:49
*** jthopkin has quit IRC21:49
*** sarob has joined #openstack-meeting-321:51
*** sarob has quit IRC21:55
*** david-lyle has quit IRC21:58
*** jtomasek has quit IRC22:17
*** eguz has joined #openstack-meeting-322:40
*** eghobo has quit IRC22:43
*** wchrisj has quit IRC22:46
*** julim has joined #openstack-meeting-322:51
*** sarob has joined #openstack-meeting-322:54
*** julim has quit IRC22:59
*** sarob has quit IRC23:00
*** eguz has quit IRC23:00
*** ftcjeff has quit IRC23:02
*** mfer has quit IRC23:20
*** carl_baldwin has quit IRC23:29
*** eghobo has joined #openstack-meeting-323:34
*** julim has joined #openstack-meeting-323:42
*** markmcclain has joined #openstack-meeting-323:45
*** cnesa2 has quit IRC23:56
*** dguitarbite has joined #openstack-meeting-323:57
*** sarob has joined #openstack-meeting-323:57

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