Wednesday, 2014-03-26

*** banix has joined #openstack-meeting-300:05
*** mestery has quit IRC00:23
*** peristeri has joined #openstack-meeting-300:29
*** banix has quit IRC00:31
*** yamahata has quit IRC00:34
*** SumitNaiksatam has quit IRC00:36
*** cjellick has quit IRC00:41
*** d0ugal has quit IRC00:53
*** banix has joined #openstack-meeting-300:56
*** d0ugal has joined #openstack-meeting-301:07
*** eguz has quit IRC01:18
*** devlaps1 has quit IRC01:36
*** peristeri has quit IRC01:42
*** alexpilotti has quit IRC01:47
*** yamahata has joined #openstack-meeting-301:58
*** vkozhukalov has joined #openstack-meeting-302:31
*** devlaps has joined #openstack-meeting-303:03
*** banix has quit IRC03:07
*** wchrisj has quit IRC03:43
*** mestery has joined #openstack-meeting-303:51
*** lcheng has joined #openstack-meeting-304:14
*** david-lyle has joined #openstack-meeting-304:16
*** SumitNaiksatam has joined #openstack-meeting-304:18
*** dolphm has quit IRC04:25
*** briancurtin has quit IRC04:25
*** SumitNaiksatam has quit IRC04:25
*** mestery has quit IRC04:25
*** briancurtin has joined #openstack-meeting-304:26
*** dolphm has joined #openstack-meeting-304:27
*** eghobo has joined #openstack-meeting-304:27
*** vkozhukalov has quit IRC04:28
*** dguitarbite has joined #openstack-meeting-305:17
*** devlaps has quit IRC05:43
*** tmazur has joined #openstack-meeting-305:46
*** tqtran has quit IRC06:07
*** saju_m has joined #openstack-meeting-306:19
*** lpetrut has joined #openstack-meeting-306:44
*** eghobo has quit IRC06:44
*** vkozhukalov has joined #openstack-meeting-307:02
*** jcoufal has joined #openstack-meeting-307:04
*** saju_m has quit IRC07:13
*** lpetrut has quit IRC07:29
*** mrunge has joined #openstack-meeting-307:32
*** MaxV has joined #openstack-meeting-307:36
*** markmcclain has joined #openstack-meeting-307:37
*** lcheng has quit IRC07:37
*** ttrifonov_zZzz is now known as ttrifonov07:40
*** MaxV has quit IRC07:47
*** johnthetubaguy has joined #openstack-meeting-307:51
*** johnthetubaguy1 has joined #openstack-meeting-307:54
*** johnthetubaguy has quit IRC07:54
*** markmcclain has quit IRC07:57
*** banix has joined #openstack-meeting-308:01
*** vkozhukalov has left #openstack-meeting-308:02
*** lpetrut has joined #openstack-meeting-308:15
*** lpetrut_ has joined #openstack-meeting-308:18
*** lpetrut has quit IRC08:19
*** tmazur has quit IRC08:20
*** banix_ has joined #openstack-meeting-308:40
*** banix has quit IRC08:41
*** banix_ is now known as banix08:41
*** banix has quit IRC08:50
*** amotoki has quit IRC08:51
*** banix has joined #openstack-meeting-308:52
*** banix has quit IRC08:52
*** jcoufal has quit IRC08:59
*** jcoufal has joined #openstack-meeting-309:00
*** MaxV has joined #openstack-meeting-309:02
*** johnthetubaguy1 has quit IRC09:23
*** MaxV has quit IRC09:42
*** MaxV has joined #openstack-meeting-309:52
*** yamahata has quit IRC10:15
*** nacim has joined #openstack-meeting-310:24
*** MaxV has quit IRC10:30
*** MaxV has joined #openstack-meeting-310:32
*** MaxV_ has joined #openstack-meeting-310:54
*** MaxV has quit IRC10:57
*** saju_m has joined #openstack-meeting-311:21
*** MaxV_ has quit IRC11:27
*** mwagner_ is now known as mwagner_notHere11:29
*** yamahata has joined #openstack-meeting-311:40
*** jcoufal has quit IRC11:52
*** jcoufal has joined #openstack-meeting-311:55
*** lblanchard has joined #openstack-meeting-312:00
*** mwagner_lap has quit IRC12:00
*** wchrisj has joined #openstack-meeting-312:04
*** yamahata has quit IRC12:06
*** MaxV has joined #openstack-meeting-312:19
*** david-lyle has quit IRC12:27
*** jcoufal has quit IRC12:30
*** jcoufal has joined #openstack-meeting-312:30
*** xuhanp has joined #openstack-meeting-312:47
*** MaxV has quit IRC12:47
*** MaxV has joined #openstack-meeting-312:47
*** jpomero has joined #openstack-meeting-312:49
*** lcheng has joined #openstack-meeting-312:55
*** mfer has joined #openstack-meeting-313:04
*** mrunge has quit IRC13:08
*** johnthetubaguy has joined #openstack-meeting-313:09
*** johnthetubaguy1 has joined #openstack-meeting-313:12
*** mwagner_lap has joined #openstack-meeting-313:12
*** johnthetubaguy has quit IRC13:13
*** julim has joined #openstack-meeting-313:16
*** yamahata has joined #openstack-meeting-313:18
*** lcheng has quit IRC13:20
*** MaxV has quit IRC13:34
*** nacim has quit IRC13:34
*** MaxV has joined #openstack-meeting-313:38
*** tqtran has joined #openstack-meeting-313:45
*** nacim has joined #openstack-meeting-313:51
*** peristeri has joined #openstack-meeting-313:51
*** dguitarbite has quit IRC14:00
*** lblanchard has quit IRC14:12
*** lblanchard has joined #openstack-meeting-314:13
*** amotoki has joined #openstack-meeting-314:18
*** dguitarbite has joined #openstack-meeting-314:30
*** alexpilotti has joined #openstack-meeting-314:39
*** mestery has joined #openstack-meeting-314:47
*** david-lyle has joined #openstack-meeting-314:53
*** banix has joined #openstack-meeting-314:59
*** julim_ has joined #openstack-meeting-315:00
*** julim has quit IRC15:01
*** yamahata has quit IRC15:03
*** mestery has quit IRC15:05
*** yamahata has joined #openstack-meeting-315:05
*** yamahata has quit IRC15:09
*** dguitarbite has quit IRC15:09
*** yamahata has joined #openstack-meeting-315:10
*** wchrisj has quit IRC15:18
*** lsmola_ has quit IRC15:19
*** peristeri has quit IRC15:32
*** perister1 has joined #openstack-meeting-315:32
*** johnthetubaguy1 is now known as johnthetubaguy15:33
*** lsmola_ has joined #openstack-meeting-315:34
*** lcheng has joined #openstack-meeting-315:37
*** saju_m has quit IRC15:43
*** cjellick has joined #openstack-meeting-315:45
*** cjellick has quit IRC15:45
*** cjellick has joined #openstack-meeting-315:46
*** wchrisj has joined #openstack-meeting-315:52
*** mestery has joined #openstack-meeting-316:01
*** xuhanp has quit IRC16:01
*** eghobo has joined #openstack-meeting-316:04
*** eghobo has quit IRC16:04
*** eghobo has joined #openstack-meeting-316:05
*** eghobo has quit IRC16:05
*** wchrisj has quit IRC16:05
*** eghobo has joined #openstack-meeting-316:06
*** lsmola_ has quit IRC16:06
*** wchrisj has joined #openstack-meeting-316:07
*** Sukhdev has joined #openstack-meeting-316:10
*** wchrisj has quit IRC16:12
*** lsmola_ has joined #openstack-meeting-316:20
*** SumitNaiksatam has joined #openstack-meeting-316:24
*** tjones1 has joined #openstack-meeting-316:25
*** dansmith has joined #openstack-meeting-316:27
*** nacim has quit IRC16:30
tjones1irc:// NovaBugScrub16:30
tjones1anyone here for bug scrubbing?16:31
tjones1#startmeeting NovaBugScrub16:31
openstackMeeting started Wed Mar 26 16:31:26 2014 UTC and is due to finish in 60 minutes.  The chair is tjones1. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:31
*** openstack changes topic to " (Meeting topic: NovaBugScrub)"16:31
openstackThe meeting name has been set to 'novabugscrub'16:31
*** tqtran has left #openstack-meeting-316:33
alexpilottihi there!16:33
tjones1hi alex16:33
tjones1so far it's just you and me16:33
alexpilottilet me take teh list of hyper-v bugs then :-)16:33
tjones1got a bunch of untagged bugs - want to take a look and see if any are yours?16:34
tjones1im just going to start through the list.  there were 6 last night and 23 this morning.  i already tagged several.  clearly people are testing!  which is good16:34
tjones1great - im going to start in case others join in and want to help out too16:36
*** devlaps has joined #openstack-meeting-316:36
*** wchrisj has joined #openstack-meeting-316:36
tjones1not sure what to use for client issues16:36
tjones1going to skip for now then16:37
tjones1again not sure so skipping16:38
tjones1guessing compute16:39
alexpilotti#link shoud specify the compute driver IMO16:40
alexpilottiwhich is libvirt16:41
*** melwitt has joined #openstack-meeting-316:41
tjones1i'll change it16:41
alexpilottiso the caption should be: ""QCOW2" image has a problem in Creating an instance on libvirt Compute node"16:41
tjones1this one could be a big deal im thinking - regression if it is a real bug16:42
tjones1and by "this one" i meant  irc://
tjones1#action show to russellb16:43
tjones1compute and havana (not sure how to tag it to havana)16:44
melwittin general I don't think bugs get tagged to specific releases16:45
tjones1hey melwitt - ok thanks.  Could you take a look at the 1st 2 in the list ?  i did not know what to make of them16:46
tjones1#link this one asked for logs16:47
melwittseems like 1297796 should be under novaclient, not nova16:48
*** mestery has quit IRC16:49
tjones1moved it16:49
melwitt1291396 has to do with nova baremetal and ironic, they need exact match in scheduler filter, so scheduler I think16:50
tjones1ok thanks16:50
melwitti.e. they want to add a scheduler filter to support baremetal16:50
tjones1ah ok - prob not icehouse ;-) as they said16:50
alexpilotti#link look slike oslo16:50
*** vkozhukalov has joined #openstack-meeting-316:51
alexpilotti"The problematic code is at least:16:51
tjones1oh ok - thanks16:51
tjones1matt says that's a dup of 128284216:53
*** Louis__ has joined #openstack-meeting-316:53
tjones1looking at logstash...16:54
*** vkozhukalov has left #openstack-meeting-316:54
tjones1don't think this is necessarily an error - the token auth is failing16:55
tjones1but it does look like a dup16:55
tjones1im gonna say network and let them decide for sure16:56
tjones1sill on that one16:58
tjones1db perhaps16:58
melwittI might put db and compute on that one. one of them needs to lock16:58
tjones1rc issue?17:00
tjones1ah they are on havana17:00
tjones1but could still be an issue17:00
*** Louis__ has quit IRC17:01
tjones1#action point out to russelb just in case17:02
melwittat best rc potential, I don't know how severe it needs to be at this point to be that17:02
tjones1i think pretty darn severe - but race condition always gets a 2nd look just in case17:02
tjones1this one seems like a corner case to me but could be wrong17:03
*** briancurtin has left #openstack-meeting-317:03
melwittyeah I think it's best to have it looked at to make sure17:03
tjones1compute then?17:03
melwittyeah compute17:04
melwittI've seen related bugs too on how state is handled when compute goes away and rpc timeout occurs. generally hangs in a "-ing" state17:05
*** wchrisj has quit IRC17:05
tjones1not good17:06
tjones1so??  scheduler??17:07
melwittI think just compute. I think in these cases if they issue "reset state" it'll go to active or error depending17:08
*** mestery has joined #openstack-meeting-317:09
tjones1this is a process bug17:10
tjones1no idea how to tag it.17:11
tjones1woa - check out this one (just opened) #link
melwittI think it would just be untagged17:13
tjones1ok i will leave the process bug17:13
tjones1but the other one?  either a misconfig or a big deal?17:14
melwittcan't tell from the information that's there17:14
tjones1yeah i asked for more info17:15
tjones1so we are done!  and only 15 minutes later17:15
tjones1peeking at rc bugs17:15
tjones12 new this morning (from the ones we just tagged) dansmith must be lurking again17:16
tjones1the other 3 are moving - we are trying to cut rc1 on friday.17:17
tjones1anything else from a bugs point of view??17:17
tjones1ok then - thanks melwitt and alexpilotti17:18
*** openstack changes topic to "OpenStack Meetings ||"17:18
openstackMeeting ended Wed Mar 26 17:18:28 2014 UTC.  Information about MeetBot at . (v 0.1.4)17:18
openstackMinutes (text):
*** melwitt has left #openstack-meeting-317:19
*** OSM has joined #openstack-meeting-317:20
*** MaxV has quit IRC17:22
*** SridarK has joined #openstack-meeting-317:26
*** mandeep has joined #openstack-meeting-317:26
*** s3wong has joined #openstack-meeting-317:26
*** mandeep has left #openstack-meeting-317:26
*** mandeep has joined #openstack-meeting-317:26
*** MaxV has joined #openstack-meeting-317:26
SumitNaiksatamSridarK mandeep s3wong: hi!17:30
*** prasadv has joined #openstack-meeting-317:30
banixhi all17:30
SumitNaiksatambanix prasadv: Hi17:30
SridarKHi SumitNaiksatam: and all17:31
SumitNaiksatami think swami was planning to join17:31
SumitNaiksatamenikanorov_: there?17:31
enikanorov_SumitNaiksatam: hi17:31
*** tjones1 has left #openstack-meeting-317:31
s3wongNeutorn advanced service meeting?17:31
*** s3wong has quit IRC17:31
SumitNaiksatamenikanorov_: hi17:31
*** ycombinator has joined #openstack-meeting-317:31
SumitNaiksatamseems we lost s3wong17:31
SumitNaiksatamok lets get started17:31
*** Swami has joined #openstack-meeting-317:31
SumitNaiksatamcgoncalves: hi17:31
SumitNaiksatam#startmeeting Networking Advanced Services17:32
openstackMeeting started Wed Mar 26 17:32:00 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:32
*** openstack changes topic to " (Meeting topic: Networking Advanced Services)"17:32
openstackThe meeting name has been set to 'networking_advanced_services'17:32
*** s3wong has joined #openstack-meeting-317:32
SumitNaiksatamSwami: hi17:32
SumitNaiksatam#info Meeting agenda: #link
SumitNaiksatams3wong: yes, right meeting :-)17:32
s3wongSumitNaiksatam: good to know17:32
SumitNaiksatam#topic Flavors Update17:32
*** openstack changes topic to "Flavors Update (Meeting topic: Networking Advanced Services)"17:32
enikanorov_on flavors, PoC code that would illustrate the idea is almost ready17:33
SumitNaiksatamenikanorov_: anything changed between last week and now?17:33
enikanorov_i plan to publish it today17:33
*** lpetrut_ has quit IRC17:33
SumitNaiksatamenikanorov_: thats is awesome17:33
banixStill cold around here :)17:33
SumitNaiksatamenikanorov_: sweet, was going to ask you if there is private branch17:33
SumitNaiksatambanix: :-)17:33
enikanorov_so probably once it done we could hve some discussion in gerrit also17:33
s3wongenikanorov_: do you have the review link (or soon)?17:33
enikanorov_s3wong: i'll send a notice, not yet17:34
s3wongenikanorov_: thanks!17:34
*** lpetrut has joined #openstack-meeting-317:34
SumitNaiksatamenikanorov_: we can wait for the patch, but in terns of design, anything changed?17:34
enikanorov_no, i don't think so17:35
SumitNaiksatamenikanorov_: our understanding was that beyond certain minimal attributes this was most going to be key:value pairs17:35
Swamiflavor_type says "public' or 'internal". what does public or internal mean.17:35
*** Kanzhe has joined #openstack-meeting-317:35
s3wongenikanorov_: still just a additional tag then, right?17:35
enikanorov_Swami: probably i need to update the wiki, 'internal' seems to be unnecessary17:36
*** MaxV has quit IRC17:36
enikanorov_SumitNaiksatam: yes17:36
SumitNaiksatamenikanorov_: per Swami's comment earlier, i think the "flavor type" is confusing17:36
SumitNaiksatamenikanorov_: if we need at all17:37
enikanorov_agree, and there no such attr in the PoC code17:37
SumitNaiksatamenikanorov_: do we?17:37
SumitNaiksatamenikanorov_: okay, so we will wait for the code17:37
SumitNaiksatamenikanorov_: perhaps a quick update of your wiki might help17:37
enikanorov_yes, I'll do that17:38
Swamiok thanks,17:38
SumitNaiksatamenikanorov_: thanks17:38
SumitNaiksatamenikanorov_: is there any notion of "namespaces" for the flavor names?17:38
enikanorov_hmm, no... i think that could be solved by service_type, so different services could have flavors with same name17:39
SumitNaiksatamenikanorov_: so you are still keeping the service_type for association with the "provider"?17:39
enikanorov_basically i'm keeping service_type for convenience of consuption17:39
enikanorov_horizon could filter flavors by the serrvice type17:40
enikanorov_or otherwise full set of flavors may be confusing to the user17:40
Swamienikanorov: can you provide some examples of "service_type" in this use case.17:40
enikanorov_loadbalancer, vpn, firewall, etc17:40
enikanorov_predefined network services that we already have17:41
enikanorov_(static set)17:41
Swamienikanorov: thanks17:41
SumitNaiksatamenikanorov_: sorry, i was confusing the "service_type" attribute with the "service_type" in STF17:41
enikanorov_well, if you're talking about providers - it's the same attribute, by nature17:42
SumitNaiksatamenikanorov_: ok17:42
banixWill the "service in a VM" be eventually a service type?17:42
enikanorov_banix: no17:43
prasadvbanix: is service in a VM be different from physical service fi they are from same vendor?17:43
enikanorov_it's not a service type in the meaning that we use17:43
SridarKperhaps a different flavor ?17:44
s3wongenikanorov_: so once haproxy works on service VM, is it the responsibility of serviceVM framework to define how to distinguish that from current impl?17:44
s3wongor do you see flavor framework allowing tenants to choose?17:44
banixwell, my point is we may have a service that does not fit into the known set of services (or more generally we do not know what service it provides)17:44
enikanorov_s3wong: most probably it will be another driver for service type LOADBALANCER that knows how to deal with haproxy in a VM17:44
SumitNaiksatamyeah, i think there are two points we are discussing here17:45
SumitNaiksatambanix and SridarK are referring to a service which is not yet defined in neutron17:45
prasadvbanix: I agree.17:45
SumitNaiksatambeing realized on a VM17:45
prasadvi think we need a way to provision such a serice which is not defined in Neutron17:45
SumitNaiksatams3wong is asking about a service known to neutron, being realized on a VM17:45
banixSumitNaiksatam: yes17:46
s3wongSumitNaiksatam: and I am talking about known service in VM17:46
SumitNaiksatams3wong i think your use case js satisfied with this model17:46
s3wongSumitNaiksatam: right17:46
SumitNaiksatamper enikanorov_'s response17:46
banixs3wong: right; two different things17:46
SumitNaiksatamthat is left to the driver17:46
SwamiThe services that are not defined in Neutron, should they be added to neutron as a "Service" extension first17:46
SumitNaiksatamcoming back to banix and SridarK's point17:46
SridarKSumitNaiksatam: actually i was just mentioning different realizations (or implementations from a vendor) could be different flavors17:47
SumitNaiksatamenikanorov_: there is always a possibility of defining a new flavor type, right?17:47
SumitNaiksatamSridarK in that case i think your use case is similar to s3wong's17:47
enikanorov_SumitNaiksatam: yes. flavors are defined by admin, and could be listed by users17:47
banixswami: not necessarily17:47
SumitNaiksatamso banix's use case17:47
SumitNaiksatamenikanorov_: yes assuming, that the admin defines such a flavor17:48
SridarKSumitNaiksatam: yes17:48
SumitNaiksatamthe part that is a little inflexible here is about the "admin defining" the flavor17:48
SumitNaiksatamsince this is a matter of implementation and configuration17:48
s3wongenikanorov_: so in this case, service_type can be defined by admin?17:49
enikanorov_s3wong: defined - no, specified - yes17:49
SumitNaiksatamwe don't a framework to configure this dynamicallhy17:49
enikanorov_so may be trying to answer a question on how to distinguish haproxy-on-host vs haproxy-on-vm17:49
SumitNaiksatambanix: i see this as an evolution of the "flavor" framework17:49
enikanorov_i don't see why a user may want to know that17:49
SumitNaiksatamenikanorov_: do you agree?17:49
banixSumitNaiksatam: yes to your earlier comments and this one too17:49
Kanzhebanix: SumitNaiksatam enikanorov_ Service-type should be a list of Neutron services and a generic type for all services that is not defined by Neutron.17:50
enikanorov_SumitNaiksatam: defining a service type is something that affects neutron core very deeply17:50
enikanorov_i'm not sure we wand to really define service_type dynamically17:50
SumitNaiksatamenikanorov_: that is an artifact of the design today17:50
s3wongenikanorov_: user may not want to know whether haproxy runs on VM or lxc?17:51
banixkanzhe: or having one specific to those realized in a VM; maybe?17:51
enikanorov_in my mind that means that we would need to load a plugin that supports this new service type17:51
SumitNaiksatamenikanorov_: and i agree that it cannot change overnight17:51
KanzheNeutron's XaaS API is a service-configuration API. If a service is configured OOB, then admin should be able to make it available to tenants.17:51
enikanorov_SumitNaiksatam: so it goes don to dynamic plugin loading17:51
SumitNaiksatamenikanorov_: it may not be a "generic" plugin17:51
SumitNaiksatamenikanorov_: and that plugin can decide what modules to load dynamically17:52
Kanzhebanix: Whether a service is realized in a VM or physical appliance should be captured by flavors.17:52
s3wongKanzhe: yes (as enikanorov_ mentioned above)17:52
enikanorov_anyway, I've seen objections to such kind of dynamic stuff from salv-orlando17:52
enikanorov_Kanzhe: may be captured by flavors17:52
enikanorov_but there could be no need17:53
banixkanzhe: agree; was wondering if the service in a VM being defined can be of a flavor on ts own….17:53
KanzheSumitNaiksatam: yes, the "generic" plugiin really just do the insertion.17:53
SumitNaiksatamregardless, i think what we need to agree on is, that if we follow the current path of flavors it should not preclude someone from being able to dynamically define services17:53
SumitNaiksatami think if we have agreement on that here, we are good for now17:53
SumitNaiksatameveryone agree that the current flavors (as defined by enikanorov_ here) will allow that?17:54
Kanzheenikanorov_: I meant the services other than LB, VPN, FW.17:54
SumitNaiksatamKanzhe: agree?17:54
KanzheSumitNaiksatam: yes.17:54
s3wongKanzhe SumitNaiksatam: somewhat like ML2 having a generic plugin, and everything else can be "service driver"17:54
SumitNaiksatams3wong: ye17:54
SumitNaiksatamok good17:54
enikanorov_Well, technically, you can specify any service_type because it is merely a string. but with current design it would be pointless17:54
SumitNaiksatamlets wait for enikanorov_'s PoC and take it from there17:55
SumitNaiksatammoving on17:55
*** s3wong has quit IRC17:55
*** Louis__ has joined #openstack-meeting-317:55
SumitNaiksatam#topic Group Policy requirements of advanced services17:55
*** openstack changes topic to "Group Policy requirements of advanced services (Meeting topic: Networking Advanced Services)"17:55
*** s3wong has joined #openstack-meeting-317:55
SumitNaiksatamso we had this on the agenda for the past two weeks17:55
SumitNaiksatambut we did not get to it17:56
SumitNaiksatami would like to prioritize it this time17:56
*** lpetrut has quit IRC17:56
SumitNaiksatamso essentially for those not familiar with the "group policy" work, we are defining a policy abstraction17:57
SumitNaiksatameach policy is comprised of rules17:57
SumitNaiksatameach rule has a classification, and a corresponding action17:57
SumitNaiksatamone of the actions is "redirect"17:57
*** saju_m has joined #openstack-meeting-317:57
SumitNaiksatamredirect could be to a service or a service chain17:58
SumitNaiksatamthis is all captured here: #link
SumitNaiksatamso at a high level, those abstractions expect some level of advanced services support from existing neutron abstractions17:59
* cgoncalves waves to service chain :)17:59
SumitNaiksatamin the case of redirect to an independent service17:59
SumitNaiksatamwe are somewhat covered (assuming we are able to merge the service_context notion)17:59
KanzheSumitNaiksatam: should we get consensus on service insertion framework before go to GP redirect details?18:00
banixOne thing we discussed briefly was the insertion context and how that could be differnt for policies ...18:00
SumitNaiksatamone sec18:00
s3wongSumitNaiksatam: in that case, service-context needs to be defined outside of group-policy (which has no such knowledge)18:00
banixSumitNaiksatam: gyes, o ahead please18:00
banixyes, go ahead please18:00
SumitNaiksatamKanzhe: can you clarify what exactly you are referring to as "service insertion framework"?18:00
KanzheSumitNaiksatam: insertion context. :-)18:01
SumitNaiksatamjust so that we are all on same page18:01
SumitNaiksatamKanzhe: you mean the "service_context" being introduced here: #link
SwamisumitNaiksatam: Is the service insertion context driven by the group policy18:01
s3wongKanzhe: insertion context, is that the same as service context?18:02
SumitNaiksatamif so we have discussed this in the past two meetings18:02
KanzheSumitNaiksatam: s3wong yes.18:02
SumitNaiksatamand i believe we all agree on the need for this18:02
SwamiOr service insertion has to be configured first for the service types and then we need to configure the group policy.18:02
SumitNaiksatamhence i am not even bringing that up today18:02
SumitNaiksatamSwami: one sec18:02
SumitNaiksatamSwami: we will get to that18:02
SumitNaiksatami think we all agree on the need for the service_context for service insertion?18:03
Swamisumit: thanks18:03
s3wongSumitNaiksatam: when does the service_context get instantiated - I don't think there is a consensus18:03
SumitNaiksatamok so my question about agreement is in the context of the neutron elemental abstractions18:03
SumitNaiksatamthat is without group policy18:03
SumitNaiksatamlets first base line off that18:03
KanzheSumitNaiksatam: agree.18:04
SwamisumitNaiksatam: Yes I like that18:04
s3wongSumitNaiksatam: the need of service_context, yes - we agreed on that last week18:04
SridarKSumitNaiksatam: One clarification - since we model the service_context as a service attribute what will we specify ?18:05
SumitNaiksatamso without group policy we think we are good with service_context for inserting existing neutron services as independent entities18:05
SumitNaiksatamSridarK: not sure i understand18:06
s3wongSridarK: have we agreed on having service_context as part of service?18:06
KanzheSumitNaiksatam: there is still a concern that the current service context is hard for tenant to consume.18:06
SridarKin the redirect18:06
SridarKsince service context is not a resource18:06
SumitNaiksatamKanzhe: the service_context does not always have to be exposed to the user18:06
SumitNaiksatamKanzhe: or rather it can be optional18:06
SridarKin the redirect do we specify the service instance ?18:06
*** s3wong has quit IRC18:07
SumitNaiksatamSridarK: hang, we are not yet talking redirect18:07
SridarKok :-)18:07
prasadvyes service context  would be needed for insertion18:07
*** jcoufal has quit IRC18:07
*** s3wong has joined #openstack-meeting-318:07
KanzheSumitNaiksatam: yes for default insertion. If a service needs to be inserted other than the default, tenant must specify through the service context.18:07
SumitNaiksatamSridarK: want to first address that service_context is good for services as they are today (no group policy)18:07
SumitNaiksatamenikanorov_: sound okay so far with service_context?18:07
s3wongKanzhe: would that be something appropriate for tenant to specify?18:08
SridarKSumitNaiksatam: sorry that i am on board with - my confusion was on the redirect - i will wait18:08
SumitNaiksatamSridarK: np18:08
s3wongor do tenants consume network services as a service?18:08
Kanzhes3wong: that was the concern with the current service_context.18:08
SumitNaiksatams3wong: this does not have to be one or the other18:08
enikanorov_SumitNaiksatam: yes18:08
SumitNaiksatamenikanorov_: ok18:08
SumitNaiksatams3wong: as discussed above, the default consumption model might not require providing the service_context18:09
enikanorov_sorry, need to step out of pc18:09
SumitNaiksatams3wong: so user may or may not specify it18:09
SumitNaiksatamactually that is what we are doing with the FWaaS patch18:10
s3wongSumitNaiksatam: certainly - I just think it is difficult for tenant to specify service_context outside of default18:10
*** Sukhdev has quit IRC18:10
SumitNaiksatams3wong: fine, but we don't necessarily take that option away18:10
SumitNaiksatam* don't have to18:11
s3wongSumitNaiksatam: OK18:11
SwamisumitNaiksatam: You mentioned that the user need to specify the service_context, so how does Neutron select the service_context?18:11
SumitNaiksatami think we tend to get rat holed in the discussion about whether service_context is friendly to the user or not, but really its optional18:11
SumitNaiksatamSwami: the service_context has to come from somewhere18:12
SumitNaiksatamSwami: either the user provides it, or the backend infers it18:12
SumitNaiksatamSwami: the service_context is merely a hook to provide this18:12
s3wongSumitNaiksatam: well, if it isn't supposed to be specified by users, then we have to think about when the service context gets instantiated18:12
s3wongSumitNaiksatam: so it isn't so much about being user friendly, just understanding when do we know where a service is supposed to be inserted18:13
SumitNaiksatams3wong: as of now, when a service gets inserted does not change by the introduction of the service_context18:14
mandeeps3wong: I was hoping the "when/where" question to be driven by policy and "how" to be driven by service-context18:14
s3wongAnyway - group policy and redirect, sorry for diverting the discussion :-)18:14
SumitNaiksatammandeep: exactly18:14
mandeepSumitNaiksatam: I agree these are orthogonal concerns18:14
SumitNaiksatamok it seems we are more or less in agreement18:15
SumitNaiksatamon the single/independent service as neutron understands it today18:15
SumitNaiksatamso moving on in the context of group policy18:16
SumitNaiksatamnow let's address the concerns on if/how the service_context would help for single services18:17
mandeepThat way we have a single language for the user to specify service policy - independent of it being security/access issue or QoS or a richer service offered by an external/VM entity18:17
SumitNaiksatami think i put some folks on hold, please go ahead :-)18:17
*** pcm_ has joined #openstack-meeting-318:17
* mandeep was just agreeing with you, just using a lot of text to say that18:18
SumitNaiksatammandeep: yeah, i think what you are saying is that the policy will drive the service_context in that case18:18
*** s3wong has quit IRC18:18
*** s3wong has joined #openstack-meeting-318:19
banixSumitNaiksatam: the idea is having a policy context as well. right?18:19
SumitNaiksatambanix: can you elaborate?18:19
banixIf I understand it correctly a service oe a service chain gets inserted in a service context and then18:20
SumitNaiksatambanix: lets break that down a bit18:20
banixthe context required for instantiating the service(s) get drived depending on the services…18:20
SumitNaiksatambanix: before we get to service chains18:21
SumitNaiksatambanix: lets first address the use case of redirect to a single service18:21
s3wongbanix: actually I think we need a service context to see where a service is inserted, which may include a chain18:21
SumitNaiksatambanix: and whether the service_context addresses that18:21
SridarKSumitNaiksatam: If we take a fw usecase  with a fw created on a set of routers (service context), in the group policy - u would have a classifier and a redirect to that fw instance ?18:22
SumitNaiksatamnote that in this case the service_context is internal to the system18:22
SumitNaiksatamthe user who is interfacing with the system at the group policy abstraction level does not deal with the service-context directly18:22
SumitNaiksatambanix: ok good18:23
SumitNaiksatamSridarK: yes18:23
s3wongSumitNaiksatam: so going back to the earlier point, a plugin would need to populate a service_context according to policy?18:23
SumitNaiksatams3wong: yes18:23
SridarKSumitNaiksatam: ok makes sense thanks18:24
SumitNaiksatams3wong:  this might be concert with the flavor/type of that service18:24
SumitNaiksatams3wong: but we ideally want to hide the service_context abstraction for the group policy user18:24
s3wongSumitNaiksatam: in this case, service_context needs to be part of something else other than the actual service object18:24
s3wongor even flavor18:25
banixyes when the policy gets defined (or contracts are defined with consumer and providers specified) …. yes part of the contract/policy18:25
SumitNaiksatams3wong: why, i would argue that it needs to be part of each service so that there is a common programmable hook in each service18:25
s3wongSumitNaiksatam: hiding it from group-policy for sure - I don't advocate adding insertion point as part of policy language :-)18:26
banixsumit you were going to breakdown something18:26
SumitNaiksatams3wong: the policy "plugin" populates that service_context, and the service implementation handles it's implementation/insertion18:26
SumitNaiksatambanix: i was breaking down in to the case of redirect to a single service, versus to a chain18:27
s3wongSumitNaiksatam: because a plugin gets policy info, but plugin may not have access to the service object itself18:27
banixSumitNaiksatam: so this implies we do not need a policy context18:27
SumitNaiksatambanix: i would imagine that the policy context you are referring to is the provided contract?18:27
SumitNaiksatambanix: ok good18:28
SumitNaiksatams3wong: yes, plugin may not directly deal with the service18:28
OSM Do we need to separate service definition (create) and instantiation (launch). Service context needs to be specified to instantion - by policy in some cases18:28
SumitNaiksatams3wong: the redirect can be to a "contract" which wraps the service18:29
SumitNaiksatami think the discussion is getting a bit muddled because we have to two cases for services (1) neutron services which are already defined and which have their own plugins (that can do the insertion based on the context)18:30
*** lpetrut has joined #openstack-meeting-318:30
SumitNaiksatam(2) generic services which are not recognized by neutron, and for which the policy plugin implementation might have to do additional operations18:31
s3wongSumitNaiksatam: that means we need to extend EPG to include service18:31
SumitNaiksatams3wong: probably not18:31
banixs3wong: hopefully not; why?18:31
SumitNaiksatams3wong: the contract can have a relationship to a service_type18:31
SumitNaiksatamfolks we are over our time18:32
SumitNaiksatamthe following meeting is also chaired by me18:32
SumitNaiksatamso we can go a little over18:32
SumitNaiksatami am sure SridarK RajeshMohan and other FWaaS folks won't mind18:32
*** s3wong has quit IRC18:33
SridarKno worries18:33
prasadvsumitnaiksatam: you case (1) means that independent of policy service context needs to be deinfed?18:33
SumitNaiksatamhowever we had another agenda item which Swami had brought up18:33
SumitNaiksatamprasadv: no18:33
*** s3wong has joined #openstack-meeting-318:33
SumitNaiksatamprasadv: it just means, that we need to figure how we can leverage the existing neutron service implementations within the policy plugin orchestration18:34
s3wongSumitNaiksatam: in that case, I still don't understand - in case of not having group-policy - how we can populate service_context18:35
SumitNaiksatamprasadv: so we can have a southbound "plugin driver" mechanism that can handle this18:35
SumitNaiksatams3wong:  ok so in case of not having group-policy the simplest way is:18:35
SumitNaiksatams3wong: the backend has a default insertion model, or18:35
SumitNaiksatamand in which case it populates the service-context18:36
SumitNaiksatams3wong: or the user provides the service-context18:36
s3wongSumitNaiksatam: backend meaning LBaaS, or even more specific like haproxy driver?18:36
prasadvsumitnaiksatam: is the plugin driver under policy? or service?18:36
SumitNaiksatams3wong: it could be a combination of the service plugin and the service driver18:37
RajeshMohanHi Sumit18:37
SumitNaiksatamRajeshMohan: hi, we will start FWaaS in a munute18:37
SumitNaiksatami was saying earlier that we had another item on the agenda for this week18:39
SumitNaiksatamSwami: we have run over by a bit, are you okay if we discuss next week>18:39
SumitNaiksatamok folks on the group policy discussion, i think we need to take this discussion to tomorrow's meeting18:41
banixThanks everybody18:41
SumitNaiksatambut good start ;-)18:41
cgoncalvesSumitNaiksatam: sorry to disturb. regarding this meeting, would there be any interested in discussing the proposal I shared on the mailing list sometime here, or in another neutron meeting, or off IRC meeting?18:41
SwamiSumitNaiksatam: Ok we can discuss next week.18:41
SumitNaiksatamcgoncalves: thanks for brining that up18:41
SumitNaiksatamcgoncalves: yes sure lets put it on the agenda for the next week18:42
* banix is totally disturbed/distracted with the discussion on #openstack-neutron about firewalls, hybrid plugins, and vif_details….18:42
SumitNaiksatambanix: no worries, that's a fire burning18:42
SumitNaiksatamok lets wrap for today18:42
cgoncalvesSumitNaiksatam: ok. I was not sure whether we should bring it to the advanced service meeting or other neutron meeting18:42
cgoncalvesSumitNaiksatam: thanks.18:42
SumitNaiksatamcgoncalves: your call18:43
*** Swami has left #openstack-meeting-318:43
*** openstack changes topic to "OpenStack Meetings ||"18:43
openstackMeeting ended Wed Mar 26 18:43:06 2014 UTC.  Information about MeetBot at . (v 0.1.4)18:43
openstackMinutes (text):
banixTrying to find out if it affect our plugin; do you know?18:43
SumitNaiksatamcgoncalves: we have too much to discuss and not as much time18:43
banixThanks again!18:43
*** MaxV has joined #openstack-meeting-318:43
SumitNaiksatamand it's difficult to discuss certain things on a low bandwidth text channel :-)18:43
SumitNaiksatambanix, all: thanks for joining18:44
banixstarting a petition to ask SumitNaiksatam to use a shorter nick name!18:44
cgoncalvesSumitNaiksatam: I understand. maybe start discussing on the email thread I started shoudl be easier for everyone.18:44
SridarKbanix: copy paste :-)18:44
Louis__+1 for email18:44
*** s3wong has quit IRC18:44
SumitNaiksatambanix: my apologies, but thought auto complete should work, right? :-)18:44
cgoncalvesbanix: auto-complete (tab key)18:45
SumitNaiksatamSridarK banix: tab complete18:45
cgoncalves+1 :-)18:45
banixit does but still i end up typing it most of the time; no apologies needed; just kidding18:45
SumitNaiksatamok lets gets started with FWaaS18:45
SumitNaiksatam#startmeeting Networking FWaaS18:45
openstackMeeting started Wed Mar 26 18:45:52 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:45
*** openstack changes topic to " (Meeting topic: Networking FWaaS)"18:45
openstackThe meeting name has been set to 'networking_fwaas'18:45
SumitNaiksatamSridarK RajeshMohan: there?18:46
RajeshMohanSumitNaiksatam: Hi18:46
SumitNaiksatamRajeshMohan: apologies for the delay, but it would be nice to have you in the previous meeting as well18:46
RajeshMohanSumitNaiksatam: I am sorry. I had a clash18:47
SumitNaiksatamnot sure if we have gary or yi today?18:47
RajeshMohanSumitNaiksatam: I am trying to reschedule the other one18:47
SumitNaiksatamRajeshMohan: ok great18:47
SumitNaiksatamRajeshMohan: lots of discussion on service context over there18:47
*** mandeep has left #openstack-meeting-318:47
RajeshMohanSumitNaiksatam: I will go over them18:47
SumitNaiksatam#topic Service Insertion and Firewall18:47
*** openstack changes topic to "Service Insertion and Firewall (Meeting topic: Networking FWaaS)"18:47
SumitNaiksatamRajeshMohan: is the earlier issue raised by akihiro fixed?18:48
SumitNaiksatamRajeshMohan: we have not rebased since march 6th18:49
RajeshMohanSumitNaiksatam: No, I was waiitng for kevin's patch to merge. I see that it is merged now18:49
SumitNaiksatamRajeshMohan: the one on the UTs?18:49
RajeshMohanSumitNaiksatam: I can put back the 'router-in-use'18:49
RajeshMohan'router-in-use" check should take care of one issue he raised18:49
SridarKSo with this the router will not get deleted when fw-delete happens ?18:50
SumitNaiksatamRajeshMohan: ok, lets get it wrapped up and have akihiro agree to it18:50
RajeshMohanThe other one was about router not gettng deleted18:50
SumitNaiksatamRajeshMohan: i think the latter should be fixed now, right?18:50
RajeshMohanSridarK: any  updates on that - sorry I cannot find the link to your patch18:51
*** nacim has joined #openstack-meeting-318:51
RajeshMohanSumitNaiksatam: those two will take care of what looked like bugs18:51
SridarKone issue pending is Akihiro comments on using a ',' delimeter18:51
SridarKoops sorry18:52
SridarKu asked abt the bug18:52
SridarKyes that will take care of one of Akihiro's issues18:52
SumitNaiksatamok good18:52
SumitNaiksatamso RajeshMohan lets reach out akihiro once we have rebased and patched18:52
SumitNaiksatamthis will of course not mereg18:52
RajeshMohanSumitNaiksatam: there was general issue on file18:53
SumitNaiksatambut if we get his approval, it will be easier to proceed once Juno opens18:53
SumitNaiksatamRajeshMohan: what was that?18:53
*** MaxV has quit IRC18:53
RajeshMohanSumitNaiksatam: 1 sec18:54
*** MaxV has joined #openstack-meeting-318:54
SumitNaiksatamSridarK: how is the CLI patch looking18:54
SumitNaiksatamSridarK: are we set?18:54
SridarKone issue pending is Akihiro comments on using a ',' delimeter for the resource list18:54
*** jamielennox is now known as jamielennox|away18:54
SridarKi used a space delimiter to keep it consistent with FW rules list18:55
SridarKthere is no religion there just trying to maintain some consistency18:55
SridarKwanted to get ur opinion and i can change it18:55
RajeshMohanSumitNaiksatam: I cannot find it - it was the discussion on defining 'routers', 'network' etc in common file18:56
RajeshMohanSumitNaiksatam: He was not sure if all types will make sense for all services18:56
SumitNaiksatamSridarK: ah ok, i think we can go with what Akihiro wants (comma separated)18:56
SridarKok done18:57
RajeshMohanSumitNaiksatam: Not sure if we discussed that in Advanced Services meeting18:57
SumitNaiksatamSridarK: we can later, change the firewall rules to keep consistency18:57
SumitNaiksatamRajeshMohan: ok18:57
SumitNaiksatamRajeshMohan: i think i recall that comment in the review18:57
SumitNaiksatamRajeshMohan: lets leave it the way it is now18:57
SumitNaiksatamRajeshMohan: the reviewer can get back on this if its still an issue18:58
RajeshMohanSumitNaiksatam: Ok. I will address the comments and rebase once Sridar's patch merges18:58
SumitNaiksatamRajeshMohan: SridarK's patch?18:58
RajeshMohanSumitNaiksatam: yes - router not getting deleted fix18:58
SridarKRajeshMohan: that is merged18:59
SumitNaiksatamRajeshMohan: yeah18:59
SumitNaiksatamRajeshMohan: that happened on March 15th18:59
RajeshMohanSumitNaiksatam SridarK: Ok. Then I will rebase18:59
SumitNaiksatamRajeshMohan: ok thanks18:59
SridarKRajeshMohan: one other issue was when we try to delete these routers (which has no i/f) - Akihiro's issue18:59
SridarKor rather a follow on to Akihiro's issue19:00
SridarKi have an email out to u19:00
*** johnthetubaguy has quit IRC19:00
SumitNaiksatamSridarK: i think i glossed over that19:00
SumitNaiksatamSridarK: can't seem to recollect the context19:00
SridarKSumitNaiksatam: when we delete - there was an issue on the db19:01
SumitNaiksatamSridarK: ok19:01
SumitNaiksatamSridarK: is the comment on RajeshMohan's patch?19:01
SridarKSumitNaiksatam: No details in email to u guys19:01
RajeshMohanSridarK: I also seem to be missing some context - To me 'Akihiro's issue' and 'router not deleted' are same19:01
SridarKI will resend the email19:02
SumitNaiksatamSridarK: ok great, sorry about that19:02
SridarKRajeshMohan:   /opt/stack/neutron/neutron/db/ ->  ---------------------------------------------------------------------- > /usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/ -> "Multiple rows were found for one()") (Pdb)19:02
*** MaxV has quit IRC19:03
SridarKwas the traceback19:03
RajeshMohanSridarK: ok - got that19:03
SridarKthis copy paste comes out terribly :-)19:03
SridarKRajeshMohan: ok great19:03
SumitNaiksatamSridarK: but it did the trick :-)19:03
RajeshMohanSridarK: I need to fix that as well along with rebase19:03
SridarKRajeshMohan: ok19:04
SumitNaiksatamRajeshMohan: if possible we should have a UT to cover that case19:04
RajeshMohanSumitNaiksatam SridarK: Will have a patch out by end of this week19:04
SumitNaiksatamRajeshMohan: ok thanks19:05
SridarKok cool i will also refactor the CLI to change as per Akihiro's comment for ','19:05
SumitNaiksatamwe should focus on getting this in before we take up other things19:05
SumitNaiksatamlets not lose our tempo on this19:05
SridarKso we should be good to go when Juno reopens19:05
SumitNaiksatamSridarK: yeah, thanks19:06
*** Louis__ has quit IRC19:06
RajeshMohanSooner the better - I need to work on our plugin as well after that19:06
SumitNaiksatamRajeshMohan: ok cool19:06
*** openstack changes topic to " (Meeting topic: Networking FWaaS)"19:06
openstackRemoving item from minutes: <ircmeeting.items.Topic object at 0x2969210>19:06
SumitNaiksatam#topic Zones19:07
*** openstack changes topic to "Zones (Meeting topic: Networking FWaaS)"19:07
SridarKso this will be a primary target for Juno19:07
SumitNaiksatamSridarK: I think we need to discuss as a team19:08
SumitNaiksatamper our earlier discussion this was definitely a priority19:08
SridarKi think we had some points down19:08
RajeshMohanAll firewalls have zones - though the definition of zones may differ a bit19:08
*** markmcclain has joined #openstack-meeting-319:08
SridarKbut will be good to cover it as a team19:08
SumitNaiksatambut still good to have a discussion19:08
SumitNaiksatamRajeshMohan: you wanted to discuss something beyond what we have currently defined?19:09
RajeshMohanSumitNaiksatam SridarK: We already discussed this in the HK summit19:09
SridarKRajeshMohan: yes i think some minor diferences19:09
SridarKacross vendors19:09
RajeshMohanI propose that we start working on the patch - after we document the API19:09
SridarKbut seems like nothing too controversial hopefully and we can have a model that works for all19:09
SumitNaiksatamRajeshMohan: definitely, if we can crystallize the resource model and the API, we can proceed on this19:10
SridarKperhaps we can start the discussions - i can start capturing into a doc19:10
RajeshMohanSridarK: let's document what we mean by zones and get folks to agree19:10
SridarKso we have something out there for all to comment19:10
SridarKRajeshMohan: we are on the same page :-)19:11
RajeshMohanzones - collection of neutron ports is what we were pushing in the lcehouse design summit19:11
RajeshMohanSridarK: ok great19:11
SridarKI see some similarities with our discussions on insertion context19:11
SridarKservice context19:12
*** OSM has left #openstack-meeting-319:12
RajeshMohanSridarK: yes - we have to link the two at some stage - maybe at validation stage19:12
SumitNaiksatamyeah, one general comment (i think we discussed this earlier) is that not every construct of a service needs to be represented at the neutron level19:13
SumitNaiksatami do agree that from a firewall perspective, zone is a fundamental construct19:13
SridarKSumitNaiksatam: yes i think we need to discuss more on that19:13
SumitNaiksatamhowever, i think we will need to convince the community that certain use cases cannot be satisfied if zones are not defined19:14
*** wchrisj has joined #openstack-meeting-319:14
RajeshMohanAll firewalls have zones - is that not good enough :-)19:14
SumitNaiksatamRajeshMohan: probably not19:15
RajeshMohanwe need different policy for different pair of zones19:15
SumitNaiksatamRajeshMohan: all switches mostly support VLANs19:15
SumitNaiksatamRajeshMohan: but we don't expose them in the neutron abstraction19:15
SumitNaiksatammay not be the best analogy19:15
SridarKSumitNaiksatam: i think u are saying to justify this new construct of szone19:15
SumitNaiksatami am just playing the devil's advocate19:16
SridarKinstead of just saying collection of ports19:16
RajeshMohanSumitNaiksatam: Ok - we will try to build a case for firewall zones19:16
SumitNaiksatamRajeshMohan: great19:16
*** Louis__ has joined #openstack-meeting-319:17
SumitNaiksatam#topic open discussion19:17
*** openstack changes topic to "open discussion (Meeting topic: Networking FWaaS)"19:17
SumitNaiksatamanything else we need to discuss?19:17
SridarKSummit prep ?19:17
SumitNaiksatamthanks SridarK just typing19:17
SridarKwe should discuss will all folks19:17
SumitNaiksatami did post a summit session19:17
SridarKoh ok :-)19:17
RajeshMohanI want to propose an extension to firewall "Firewall DPI Configuration"19:18
SumitNaiksatamlike last time19:18
RajeshMohanI can get a BP ready for that19:18
SumitNaiksatamRajeshMohan: great19:19
SridarKRajeshMohan: i attribute my baldness to debugging DPI issues on a NPU ;-)19:19
RajeshMohanWe need a knob at Firewall level to say that "IPS is enabled", "Gateway AntiVirus is enabled" and few more DPI based firewall services19:19
SridarKso +1 on that19:19
SumitNaiksatami think we need to get into a room (at least some of us) to converge on the priority of topics19:19
SumitNaiksatamanything more?19:20
SridarKSumitNaiksatam: yes that will be great19:20
RajeshMohanSumitNaiksatam: Sure. I am sure this will be priority for most firewall vendors19:20
RajeshMohanSumitNaiksatam SridarK: Just to confirm. What are next actions on Firewall zones?19:20
RajeshMohanSumitNaiksatam SridarK: Are we going to work on a patch based on last design summit?19:21
SridarKLets start some discussion and capture into a doc19:21
SumitNaiksatamSridarK: +119:21
RajeshMohanSridarK: IMO, we already discussed this in last two summits. We can have a quick discussion this time19:22
*** nacim has quit IRC19:22
SridarKRajeshMohan: ok lets get some convergence amongst the sub team19:22
SridarKso there are no issues raised later on19:22
RajeshMohanSridarK SumitNaiksatam: Sorry for pushing on Firewall zones but this is important for DELL plugin19:23
SumitNaiksatamSridarK: yeah, i think we need to convince the rest of the community19:23
RajeshMohanI am ok with one more discussion but we have discussed this a lot already19:23
SridarKRajeshMohan: Agreed very important for us also and also for other participants19:24
RajeshMohanSumitNaiksatam SridarK: Ok. Let's start with documentation19:24
SumitNaiksatamRajeshMohan: there is also always an option of having vendor specific extensions19:24
SumitNaiksatamRajeshMohan: document sounds like a good idea19:24
SumitNaiksatamlets call it a wrap for today19:25
SumitNaiksatamunless there is something else19:25
RajeshMohanSumitNaiksatam SridarK: ok. Thanks19:25
*** pcm_ has left #openstack-meeting-319:25
SumitNaiksatamthanks folks for joining19:25
SridarKSumitNaiksatam: RajeshMohan ttyl19:25
*** openstack changes topic to "OpenStack Meetings ||"19:25
openstackMeeting ended Wed Mar 26 19:25:36 2014 UTC.  Information about MeetBot at . (v 0.1.4)19:25
openstackMinutes (text):
*** SumitNaiksatam has quit IRC19:31
*** SumitNaiksatam has joined #openstack-meeting-319:42
*** nacim has joined #openstack-meeting-319:46
*** nacim has quit IRC19:52
*** Louis__ has quit IRC20:03
*** julim_ has quit IRC20:03
*** saju_m has quit IRC20:11
*** mrunge has joined #openstack-meeting-320:27
*** saju_m has joined #openstack-meeting-320:30
*** david-lyle has quit IRC20:34
*** devlaps has quit IRC20:35
*** saju_m has quit IRC20:37
*** devlaps has joined #openstack-meeting-320:41
*** julim has joined #openstack-meeting-320:45
*** garyduan has joined #openstack-meeting-320:59
*** mfer has quit IRC21:02
*** wchrisj has quit IRC21:11
*** prasadv has quit IRC21:17
*** lifeless has quit IRC21:19
*** gduan has joined #openstack-meeting-321:32
*** garyduan has quit IRC21:33
*** jamielennox|away is now known as jamielennox21:35
*** jamielennox has left #openstack-meeting-321:36
*** lpetrut has quit IRC21:39
*** MaxV has joined #openstack-meeting-321:55
*** perister1 has quit IRC21:57
*** dhellmann is now known as dhellmann_22:03
*** banix has quit IRC22:04
*** ttrifonov is now known as ttrifonov_zZzz22:16
*** mwagner_lap has quit IRC22:17
*** lblanchard has quit IRC22:27
*** lcheng has quit IRC22:27
*** gduan has quit IRC22:30
*** dhellmann_ is now known as dhellmann22:31
*** lcheng has joined #openstack-meeting-322:31
*** dhellmann is now known as dhellmann_22:41
*** lcheng has quit IRC22:49
*** garyduan has joined #openstack-meeting-322:57
*** mrunge has quit IRC23:02
*** julim has quit IRC23:05
*** jtomasek has quit IRC23:25
*** alexpilotti has quit IRC23:28
*** yamahata has quit IRC23:37
*** mwagner_lap has joined #openstack-meeting-323:38
*** gduan has joined #openstack-meeting-323:52
*** garyduan has quit IRC23:53

Generated by 2.14.0 by Marius Gedminas - find it at!