Wednesday, 2014-05-07

*** SumitNaiksatam has quit IRC00:08
*** Sukhdev has joined #openstack-meeting-300:14
*** devlaps has quit IRC00:20
*** jaypipes has joined #openstack-meeting-300:23
*** chuckC has quit IRC00:25
*** SumitNaiksatam has joined #openstack-meeting-300:33
*** SumitNaiksatam has quit IRC00:39
*** yamahata has joined #openstack-meeting-300:42
*** yamahata has quit IRC00:55
*** notmyname has quit IRC01:03
*** david-lyle has joined #openstack-meeting-301:03
*** notmyname has joined #openstack-meeting-301:06
*** alexpilotti has quit IRC01:11
*** SumitNaiksatam has joined #openstack-meeting-301:13
*** lcheng_ has quit IRC01:32
*** banix has joined #openstack-meeting-301:40
*** sankarshan is now known as sankarshan_away01:48
*** Sukhdev_ has joined #openstack-meeting-301:50
*** Sukhdev has quit IRC01:50
*** Sukhdev has joined #openstack-meeting-301:52
*** notmyname has quit IRC01:54
*** notmyname has joined #openstack-meeting-301:54
*** vkmc has quit IRC01:55
*** Sukhdev_ has quit IRC01:55
*** Sukhdev has quit IRC01:56
*** david-lyle has quit IRC01:57
*** alexpilotti has joined #openstack-meeting-302:07
*** alexpilotti has quit IRC02:23
*** banix has quit IRC02:27
*** banix has joined #openstack-meeting-302:27
*** sankarshan_away is now known as sankarshan02:37
*** yamahata has joined #openstack-meeting-302:52
*** amotoki has quit IRC03:14
*** Sukhdev has joined #openstack-meeting-303:21
*** banix has quit IRC03:21
*** Sukhdev has joined #openstack-meeting-303:21
*** chuckC has joined #openstack-meeting-303:30
*** coolsvap|afk is now known as coolsvap03:34
*** amotoki has joined #openstack-meeting-303:56
*** sankarshan is now known as sankarshan_away04:06
*** sankarshan_away is now known as sankarshan04:54
*** Sukhdev has quit IRC05:21
*** jcoufal has joined #openstack-meeting-305:33
*** eghobo has joined #openstack-meeting-305:53
*** eghobo has quit IRC05:54
*** eghobo has joined #openstack-meeting-305:54
*** mrunge has joined #openstack-meeting-306:56
*** jcoufal has quit IRC07:00
*** eghobo has quit IRC07:04
*** lsmola has joined #openstack-meeting-307:09
*** lsmola2 has joined #openstack-meeting-307:17
*** MaxV has joined #openstack-meeting-307:21
*** ttrifonov_zZzz is now known as ttrifonov07:27
*** lsmola2 has quit IRC07:27
*** jcoufal has joined #openstack-meeting-307:37
*** safchain has joined #openstack-meeting-307:54
*** MaxV has quit IRC07:54
*** MaxV has joined #openstack-meeting-308:03
*** nacim has joined #openstack-meeting-308:11
*** jamie_h has joined #openstack-meeting-308:35
*** nacim has quit IRC08:54
*** nacim has joined #openstack-meeting-309:07
*** overlayer has joined #openstack-meeting-309:23
*** coolsvap is now known as coolsvap|afk09:30
*** coolsvap|afk is now known as coolsvap09:58
*** overlayer has quit IRC10:04
*** safchain has quit IRC10:08
*** overlayer has joined #openstack-meeting-310:11
*** enykeev has quit IRC10:17
*** enykeev has joined #openstack-meeting-310:21
*** yamahata has quit IRC10:43
*** overlayer has quit IRC10:47
*** overlayer has joined #openstack-meeting-310:48
*** overlayer has quit IRC10:53
*** overlayer has joined #openstack-meeting-310:53
*** coolsvap is now known as coolsvap|afk10:54
*** jcoufal has quit IRC10:54
*** jcoufal has joined #openstack-meeting-310:56
*** overlayer_ has joined #openstack-meeting-311:00
*** overlayer has quit IRC11:01
*** overlayer_ has quit IRC11:13
*** nacim has quit IRC11:16
*** sankarshan is now known as sankarshan_away11:46
*** amotoki has quit IRC11:59
*** overlayer has joined #openstack-meeting-312:01
*** d0ugal_ has joined #openstack-meeting-312:06
*** d0ugal_ has quit IRC12:09
*** mwagner_ has quit IRC12:09
*** yamahata has joined #openstack-meeting-312:28
*** yamahata has quit IRC12:33
*** sankarshan_away is now known as sankarshan12:39
*** peristeri has joined #openstack-meeting-312:40
*** lblanchard has joined #openstack-meeting-312:45
*** banix has joined #openstack-meeting-312:50
*** nacim has joined #openstack-meeting-312:54
*** banix has quit IRC13:00
-openstackstatus- NOTICE: Zuul is stuck due to earlier networking issues with Gerrit server, work in progress.13:02
*** ChanServ changes topic to "Zuul is stuck due to earlier networking issues with Gerrit server, work in progress."13:02
*** coolsvap|afk is now known as coolsvap13:07
*** julim has joined #openstack-meeting-313:08
*** ChanServ changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"13:11
-openstackstatus- NOTICE: Zuul is processing changes now; some results were lost. Use "recheck bug 1317089" if needed.13:11
*** mestery has quit IRC13:33
*** overlayer has quit IRC13:37
*** alexpilotti has joined #openstack-meeting-313:37
*** overlayer has joined #openstack-meeting-313:38
*** safchain has joined #openstack-meeting-313:41
*** mwagner_ has joined #openstack-meeting-313:54
*** overlayer has quit IRC14:00
*** markmcclain has joined #openstack-meeting-314:05
*** jpomero has joined #openstack-meeting-314:06
*** markmcclain1 has joined #openstack-meeting-314:08
*** markmcclain has quit IRC14:10
*** jpomero has quit IRC14:12
*** edleafe- has quit IRC14:12
*** edleafe has joined #openstack-meeting-314:13
*** jpomero has joined #openstack-meeting-314:15
*** shakamunyi has joined #openstack-meeting-314:16
*** d0ugal has quit IRC14:34
*** d0ugal has joined #openstack-meeting-314:47
*** d0ugal has quit IRC14:47
*** d0ugal has joined #openstack-meeting-314:47
*** cjellick has quit IRC14:53
*** cjellick has joined #openstack-meeting-314:58
*** cjellick has quit IRC15:07
*** cjellick has joined #openstack-meeting-315:07
*** banix has joined #openstack-meeting-315:08
*** david-lyle has joined #openstack-meeting-315:15
*** jcoufal has quit IRC15:20
*** shakamunyi has quit IRC15:20
*** shakamunyi has joined #openstack-meeting-315:23
*** emagana has joined #openstack-meeting-315:36
*** mrunge has quit IRC15:42
*** eghobo has joined #openstack-meeting-315:48
*** Sukhdev has joined #openstack-meeting-315:50
*** nacim has quit IRC15:52
*** lsmola has quit IRC15:58
*** lcheng_ has joined #openstack-meeting-316:04
*** tjones has joined #openstack-meeting-316:21
*** devlaps has joined #openstack-meeting-316:25
tjones#startmeeting NovaBugScrub16:30
openstackMeeting started Wed May  7 16:30:54 2014 UTC and is due to finish in 60 minutes.  The chair is tjones. Information about MeetBot at http://wiki.debian.org/MeetBot.16:30
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:30
*** openstack changes topic to " (Meeting topic: NovaBugScrub)"16:30
openstackThe meeting name has been set to 'novabugscrub'16:30
tjonesanyone here today?16:31
tjonesok - we'll i've doing finished the tagging so i'll go ahead and end the meeting.  nothing controversial there16:34
tjones#endmeeting16:34
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"16:34
openstackMeeting ended Wed May  7 16:34:53 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:34
openstackMinutes:        http://eavesdrop.openstack.org/meetings/novabugscrub/2014/novabugscrub.2014-05-07-16.30.html16:34
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/novabugscrub/2014/novabugscrub.2014-05-07-16.30.txt16:34
openstackLog:            http://eavesdrop.openstack.org/meetings/novabugscrub/2014/novabugscrub.2014-05-07-16.30.log.html16:34
*** coolsvap is now known as coolsvap|afk16:46
*** tjones has left #openstack-meeting-316:47
*** MaxV has quit IRC17:07
*** safchain has quit IRC17:11
*** rkukura has joined #openstack-meeting-317:12
*** lcheng_ has quit IRC17:20
*** pcm_ has joined #openstack-meeting-317:29
*** regXboi has joined #openstack-meeting-317:29
*** SridarK has joined #openstack-meeting-317:30
*** s3wong has joined #openstack-meeting-317:30
SumitNaiksatamhi Neutrons!17:30
s3wongHello17:30
banixPolicy Fenatics :)17:30
s3wongbanix: this is advanced service, no? :-)17:30
SridarKHi All :-)17:30
pcm_hi17:30
banixsorry wrong meeting17:30
enikanorovhi17:30
banixs3wong: got too excited :)17:31
cgoncalveshi all17:31
SumitNaiksatambanix: we welcome all! ;-P17:31
*** sballe has joined #openstack-meeting-317:31
SumitNaiksatambanix: especially policy fanatics17:31
*** Kanzhe has joined #openstack-meeting-317:31
SridarKbanix: is like an electron17:31
banix:)17:31
SumitNaiksatamok i think we have crical mass17:31
SumitNaiksatamlets get started17:31
SumitNaiksatam#startmeeting Networking Advanced Services17:31
openstackMeeting started Wed May  7 17:31:57 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.17:31
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:31
*** openstack changes topic to " (Meeting topic: Networking Advanced Services)"17:31
*** otherwiseguy has quit IRC17:32
openstackThe meeting name has been set to 'networking_advanced_services'17:32
SumitNaiksatamMeeting agenda: #link https://wiki.openstack.org/wiki/Meetings/AdvancedServices17:32
rkukurahi17:32
SumitNaiksatam#link https://wiki.openstack.org/wiki/Neutron/AdvancedServices17:32
sballehi.17:32
SumitNaiksatamsballe: hi17:32
SumitNaiksatam#topic Neutron Advanced Services'  Common Framework17:33
*** openstack changes topic to "Neutron Advanced Services' Common Framework (Meeting topic: Networking Advanced Services)"17:33
SumitNaiksatam#link https://review.openstack.org/#/c/9220017:33
SumitNaiksatamper our discussion during the past several weeks, and direction from the PTL, the above umbrella blueprint was posted17:33
SumitNaiksatamhope there were no surprises with regards to the content in that spec, it was based on the consensus until last week17:34
SumitNaiksatamif you get a chance a please review17:34
banixSumitNaiksatam: do we need to get this approved, or it simple stands to bring other pieces together?17:34
SumitNaiksatamthoughts/questions?17:34
SumitNaiksatambanix: ah good point17:34
sballeSumitNaiksatam, Is this proposal a step closer towards having a clean integration between Neutron core and the Advanced Services?17:34
gduanHi17:34
SumitNaiksatammy understanding is that it probably needs to get approved17:34
SumitNaiksatamhowever, we need to get all the dependent blueprints in17:35
SumitNaiksatamwe will follow up on the individual components in the agenda of the meeting17:35
sballeand interface? or is it more a workflow type of thing e.g. service lyfe cycle17:35
SumitNaiksatamsballe: its both17:35
SumitNaiksatambanix: does that answer17:36
sballeSumitNaiksatam, perfect. thx17:36
banixSumitNaiksatam: yes thanks17:36
s3wongSumitNaiksatam: well, at the very least, service definition isn't being pointed to the reference link in the doc17:36
SumitNaiksatamsballe: there is some amount of integration, though not perfect17:36
*** TravT has joined #openstack-meeting-317:36
SumitNaiksatamsballe: this is a step in the process of organic evolution17:36
SumitNaiksatams3wong: ??17:37
s3wongSumitNaiksatam: [3] isn't properly pointing to the document with service base definition17:37
SumitNaiksatams3wong:  do you have a new link/17:37
s3wongSumitNaiksatam: same service insertion document17:37
*** Swami has joined #openstack-meeting-317:37
Swamihi17:38
SumitNaiksatams3wong: ok, need to check17:38
SumitNaiksatams3wong:  will update accordingly17:38
emaganahi there.. bit late!17:38
SumitNaiksatammost of those references are place holders though, waiting for the gerrit blueprints to be filed17:38
SumitNaiksatamsballe: does that answer your question?17:38
s3wongSumitNaiksatam: good17:38
SumitNaiksatamhi to all those who just joined17:39
SumitNaiksatamok moving on17:39
SumitNaiksatamso since we have a high level plan, i propose that we henceforth start tracking in individual item17:40
sballeSumitNaiksatam, yes. I am looking at the BP now. I would like to see somewhere that we identify the need for a clean integration with Neutron17:40
SumitNaiksatamsballe: the whole discussion iis in the context of Neutron itself17:41
SumitNaiksatamsballe: so there are multiple touch points with neutron17:41
SumitNaiksatamsballe: or rather with the rest of neutron17:41
sballeSumitNaiksatam, I understand but I am told that the LBaaS for example manipulate the Neutron tables directly. There should be an API for that17:41
SumitNaiksatamsballe: in every component that is identified17:41
enikanorovsballe: why? lbaas is a part of neutron, it has direct access to the DB17:42
SumitNaiksatamsballe: sure, that might have been an implementation short cut17:42
enikanorovthe api is LbaaS DB plugin itself17:42
enikanorovno additional layer is needed17:42
SumitNaiksatamenikanorov: yes, i agree those are local calls17:42
SumitNaiksatamenikanorov: not REST api calls17:43
*** chuckC has quit IRC17:43
SumitNaiksatamenikanorov: perhaps what sballe is indicating is that services should access neutron through clean interfaces rather than manipulating the db tables17:43
sballeSumitNaiksatam, enikanorov IMHO we want to make sure that we have a clean interface and integration between the core of Neutron and the Advanced Services.17:43
SumitNaiksatamif indeed that is happening17:43
sballeSumitNaiksatam, Yes that was my point. Thx17:44
SumitNaiksatamsballe: agreed17:44
SumitNaiksatamenikanorov: sound okay, i think we are on the same page, right?17:44
sballeSumitNaiksatam, Can we add this item to the BP?17:44
enikanorovSumitNaiksatam: i'm actually not sure :)17:45
SumitNaiksatamsballe: yes sure, please also feel free to comment17:45
SumitNaiksatamenikanorov: ok :-)17:45
enikanorovwhile services are plugins which are within the same process accessing the same DB...17:45
sballeSumitNaiksatam, Will do.17:45
enikanorovi wonder what additional interfaces are needed to work with it?17:45
enikanorovanyway, we can discuss it offline17:46
SumitNaiksatamenikanorov: hypothetical example - you might not want lbaas code to maniplulate neutron “port” table directly17:46
sballethis was mention by markmcclain1 and mestery at some point when we talked about the neutron/LBaaS connection17:46
SumitNaiksatamsballe: is that what you had in mind?17:47
enikanorovSumitNaiksatam: well.. we're all gentlemen, we trust other's code, right?17:47
sballeSumitNaiksatam, yes along these lines17:47
enikanorovor otherwise we would be writing java17:47
SumitNaiksatamenikanorov: ha17:47
cgoncalvesenikanorov: :D17:47
SumitNaiksatamok we are getting philosophical, so we move on17:47
SumitNaiksatamthis discussion on the drinks table in atlanta :-)17:47
enikanorovsure :)17:48
sballeperfect. count me in :-)17:48
SumitNaiksatamso my earlier question to the team, regarding tracking progress on the individual components listed in the bp (going forward in this meeting)17:48
SumitNaiksatamsound okay?17:48
enikanorovsure17:48
sballeyes17:48
enikanorovi can update on flavor fw17:48
s3wongYes17:48
cgoncalvesSumitNaiksatam: yes, please continue17:48
SumitNaiksatamthat way we can have some milestones and dates17:48
SumitNaiksatamgood17:49
SumitNaiksatamso start with our favorite topic17:49
SumitNaiksatamor rather flavor17:49
banixyes17:49
s3wong"flavor-ite"17:49
enikanorovok17:49
SumitNaiksatam#topic Flavors framework17:49
*** openstack changes topic to "Flavors framework (Meeting topic: Networking Advanced Services)"17:49
SumitNaiksatamenikanorov: you are the cook!17:49
SumitNaiksatamer…chef17:49
enikanorovso... i think https://review.openstack.org/#/c/90070/ is in good shape and pretty much everything about the framework itself is covered17:50
enikanorovso please review17:50
SumitNaiksatamenikanorov: ok17:50
SumitNaiksatamquestions for enikanorov?17:50
regXboiwell, I'm going to jump in and say that going up the stack - it looks fine17:50
enikanorovhowever we've found an issue that we didn't though on much17:50
SumitNaiksatamenikanorov: my apologies, i have been behind17:50
regXboigoing down the stack, I have questions17:50
enikanorovit's not a blocker for the framework itself17:50
*** Sukhdev has quit IRC17:50
SumitNaiksatamregXboi: sure, whats down the stack17:51
enikanorovbut it's something that should be solved for the integration between flavors and particular service17:51
banixwelcome regXboi17:51
s3wongenikanorov: what is the issue?17:51
regXboiwhat I don't see is a way for someone to pick between different implementations of services by the same provider17:51
enikanorovi'm giving an example:17:51
enikanorovuser creates a service using some flavor17:51
SumitNaiksatamenikanorov: please go ahead17:51
enikanorovand then tries to create/update some part of it, which chosen implementation doesn't support17:52
enikanorovso user gets an 'unsupported' error17:52
enikanorovthe issue is that user might not know from the flavor that this feature is not supported17:52
enikanorovparticular example:17:52
enikanorovuser creates haproxy loadbalancer17:52
*** otherwiseguy has joined #openstack-meeting-317:53
enikanorovthen it tries to add PING health monitor that haproxy doesn't support17:53
*** hareeshpc has joined #openstack-meeting-317:53
enikanorov...17:53
pcm_enikanorov: seems to tie in w/my concerns about vendor validation, and client capabilities17:53
enikanorovright not it's not very clear to me how to indicate that to a user prior trying and failing17:53
s3wongenikanorov: well, I don't think flavor can be this descriptive (which health check type do you support?) - so return unsupported isn't too bad, right?17:53
enikanorovone option is to have detailed description of flavors17:54
enikanorovs3wong: it's actually bad17:54
enikanorovs3wong: because you don't know the provider now17:54
enikanorovs3wong: how can you know what you should change to get this damn feature working?17:54
s3wongenikanorov: on the flip side, if every supported features need a tag, that makes the flavor language too bloated17:55
enikanorovso looks like flavors need to include lots of stuff, or otherwise such failures will be very confusing for a user17:55
banixshouldnt you have specified this requirement when you asked for the service ?17:55
enikanorovs3wong: that's true as well17:55
gduaneven a vendor driver supports PING server, the function might work a little differently from vendor to vendor17:55
enikanorovbanix: right, but should I require each and every kind of feature?17:55
enikanorovgduan: yes.17:56
s3wonggduan: good point17:56
enikanorovso this might be solved by 'get_capabilities' call17:56
SumitNaiksatamenikanorov: so we had discussed earlier about different types of attributes17:56
enikanorovbut we need such method before flavor fw choses the provider17:56
SumitNaiksatamor capabilitites17:56
SumitNaiksatamthere are those which are common to all “types” of services17:56
pcm_enikanorov: In my L3 vendor plugins I have a BP on that. How client knows vendor capabilities17:57
*** mestery has joined #openstack-meeting-317:57
pcm_enikanorov: Though not sure how to best handle that.17:57
SumitNaiksatamthen there are those that are common “within" a service type17:57
SumitNaiksatamand then there are those which are more specific to drivers17:57
s3wongvery soon, for more complicated services, get_capabilities will return several pages worth of information17:57
enikanorovso, framework itself is flexible enough to handle this problem in various ways17:57
enikanorovbut when it comes to integration - it better to be solved in some convenient way17:58
banixs3wong: which is fine. no?17:58
gduanI doubt there is an 'accurate' description of capability17:58
enikanorovwe don't want to bloat flavors for cloud ops, but we also don't wan't to confuse users17:58
*** hareeshpc has quit IRC17:58
SumitNaiksatamenikanorov: hence the suggestion to have different categories of capabilitites17:58
s3wongbanix: user would have to sniff through the list of capabilities before a user can choose - like a product catalog17:58
*** mandeep has joined #openstack-meeting-317:59
enikanorovSumitNaiksatam: yeah, the categories are just strings, and it's all about string matching17:59
SumitNaiksatamenikanorov: i am suggesting separate API calls perhaps17:59
enikanorovso it's more about a general way of how we handle it17:59
SumitNaiksatamenikanorov: so you can say, get_service_capabilities(), get_servcice_type_capabilities(), get_service_driver_capabilities()18:00
enikanorovfor the particular example above i suggest it is solved by adding 'healthmonitor:PING' capability18:00
s3wongand then at the end, tenant might say "hey, I know Netscalar can support all the stuff i want, where can I pick that?" :-)18:00
SumitNaiksatamsomething like that, those api names might be off18:00
enikanorovs3wong: 'how' can i pick that18:00
enikanorovSumitNaiksatam: yes, that's what we will need18:01
pcm_Should this BP address this issue? https://review.openstack.org/#/c/89366/1/specs/juno/l3-svcs-vendor-client-cap.rst18:01
enikanorovso my concern is18:01
Kanzheenikanorov: then every capability should be scoped with service type.18:01
*** mestery_ has joined #openstack-meeting-318:01
enikanorovflavor maps to several providers18:01
gduanenikanorov: who should be define these capability ist?18:01
*** bmelande has joined #openstack-meeting-318:02
gduansorry typos18:02
enikanorovand then we need precise flavor to let user work with particular feature18:02
enikanorovgduan: driver's authors18:02
SridarKenikanorov: i think beyond the simple cases, the user could pick based on the vendor and the particular implementation for esoteric needs18:02
SumitNaiksatamKanzhe: there can be common capabilities (base capabilities) and then those that are specific to types18:03
enikanorovSridarK: yes, but the main goal of Flavors to hide providers from the user18:03
s3wongenikanorov: I think gduan 's point is, who is going to set up the set of meta-tags like healthmonitor:...18:03
*** hareeshpc has joined #openstack-meeting-318:03
banixenikanorov: exactly; so we are getting distanced from that18:04
enikanorovs3wong: it's done on 1) driver side 2) by cloud operator18:04
gduans3wong: yes, the superset of all possible capability names18:04
KanzheSumitNaiksatam: sure. Scope can be used to indicate common, type specific, etc.18:04
SridarKenikanorov: i agree but i am afraid that we will have something unwieldy on the more complex cases18:04
gduans3wong: then vendor drivers claim they support the subset18:04
enikanorovSridarK: choosing provider is also supported by the flavors18:04
SumitNaiksatamok, we need to move on18:04
s3wongenikanorov: I am guessing flavor framework would limit the available categories - which can be perceived as limiting vendors (disclaimer: I do NOT work for a network service vendor)18:04
enikanorovso, so i'll finish18:04
*** mestery has quit IRC18:04
SumitNaiksatamenikanorov: sure18:04
enikanorovthe issue i've told about is for integration18:04
banixSumitNaiksatam: regXboi had a question18:05
enikanorovthe framework itself is fine18:05
enikanorovso please review and approve :)18:05
regXboiso the framework is intended to hide provider from user - i get that18:05
s3wongenikanorov: yes, I agreed. The framework and workflow is fine18:05
Kanzheenikanorov: why not just provider:model for flavor. and refer to manuals for detail capabilities. :-)18:05
SumitNaiksatamyes, all please review, and we need make move forward on this topic18:05
regXboiwhat I don't see is what about specification of a particular instance of a service from a provider18:05
pcm_Can folks look at my BP, as it tries to address caps to client?18:05
regXboithat may not be flavor, but I'm not seeing it anywhere18:06
SumitNaiksatampcm_: sure, thanks18:06
s3wongKanzhe: I think that's what enikanorov wants to avoid, exposing provider brand/product names18:06
enikanorovregXboi: explain?18:06
*** mestery_ is now known as mestery18:06
SumitNaiksatampcm_’s blueprint: https://review.openstack.org/#/c/89366/1/specs/juno/l3-svcs-vendor-client-cap.rst18:06
regXboiso flavor is intended to hide provider from user18:06
enikanorovyep18:06
pcm_SumitNaiksatam: thanks. If it fits, we can use it as a forum for discussion of this part of it.18:06
s3wongpcm_: will take a look, sure18:06
regXboiwhat happens in the case where a provider has multiple instances of a service available18:06
banixpcm_: will look; thanks.18:06
regXboiand wants to allow a user to specify the instance18:07
enikanorovregXboi: multiple backends you mean.18:07
enikanorovregXboi: provider doesn't allow user to specify particular backend18:07
regXboium18:07
enikanorovbut it could be sheduled with flavors18:07
s3wongregXboi: the scheduling algorithm takes care of that, tenants don't get to choose a particular backend18:07
enikanorovsay, flavor has a tag: 'connetctions':'unlimited'18:07
regXboithat's an assumption I don't quite agree with, but ok18:07
enikanorovand that will hint sheduler to place an instance to a performance backend18:08
enikanorovregXboi: user is not in control of backends, neither provider, nor particular appliance/device18:08
enikanorovregXboi: that's whole point of abstraction18:08
regXboiok, I'll let it drop18:08
SumitNaiksatamwe can have f2f discussion in the summit as well18:09
SumitNaiksatamenikanorov: ok to move on?18:09
enikanorovSumitNaiksatam: sure, even more then once i guess18:09
enikanorovSumitNaiksatam: that's it from my side if there are no more questions18:09
*** terryw has joined #openstack-meeting-318:10
s3wongenikanorov: flavor only get 1/3 of a design session :-)18:10
SumitNaiksatamenikanorov: great thanks, that discussion was a full course meal for this meeting!18:10
SumitNaiksatams3wong: we can do more18:10
SumitNaiksatamflavor will be part of the adv services common framework discussion18:10
SumitNaiksatamso we will get 2/3rd of the time to cover the adv services topics18:11
SumitNaiksatamenikanorov: sound okay?18:11
enikanorovyes18:11
SumitNaiksatami dont know what the third topic is about18:11
SumitNaiksatami was hoping that proposer would have joined thid forum18:11
SumitNaiksatamso we could have had a coherent plan/strategy18:11
SumitNaiksatamanyway18:11
SumitNaiksatam#topic Base service definition18:11
*** openstack changes topic to "Base service definition (Meeting topic: Networking Advanced Services)"18:11
SumitNaiksatams3wong: over to you18:12
s3wong#link https://docs.google.com/document/d/1AlEockwk0Ir267U9uFDc-Q6vYsWiAcAoKtCJM0Jc5UI/edit#heading=h.v0wed816g3i118:12
SumitNaiksatamthis captures any changes we need to make to base service defintion to support insertion and chaining (and also flavors)18:12
s3wongKanzhe and I decided to merge the two topics into one document18:12
SumitNaiksatams3wong: ok18:12
*** otherwiseguy has quit IRC18:12
SumitNaiksatamso we are going to have one gerrit spec for this?18:13
s3wongSumitNaiksatam: yes18:13
SumitNaiksatamok18:13
SumitNaiksatams3wong:  can you quickly highlight the changes to the base service definition?18:13
Kanzhes3wong: The two topics are service base class definition and service insertion.18:13
mandeepSumitNaiksatam: My understanding was that we will have a different gerrit blueprint for chanining18:14
SumitNaiksatammandeep: yes thats a different spec18:14
mandeepSumitNaiksatam: I am OK either way, just asking for clarification18:14
mandeepSumitNaiksatam: OK18:14
regXboiis the list of service ports in service base class ordered or not?18:14
SumitNaiksatammandeep: we will come to that in the agenda18:14
s3wongThe ServiceBase object is used to maintain the connection mapping of where a service is being inserted18:14
SumitNaiksatammandeep: sorry i think i forgot to add that18:14
SumitNaiksatams3wong: please proceed18:14
s3wongregXboi: No - order will be determined by ... the service chaining framework18:14
regXbois3wong: thanks18:14
KanzheregXboi: servicePorts are not order. This is not serviceChaining.18:15
regXboiwasn't thinking of service chaining18:15
regXboiwas thinking of abstraction18:15
KanzheregXboi: Do you see a need for ordering?18:15
SumitNaiksatammandeep: added18:15
regXboinot sure - was asking18:15
regXboineed to think about it some more18:15
mandeepSumitNaiksatam: Thanks18:15
s3wongI added flavor to track which user defined flavor maps to this service object, and Kanzhe and me had extended ServicePort definition to cover different types of insertion, therefore just having a list of ServicePort seems to be good enough18:16
SumitNaiksatams3wong: ok, does this reconcile with the flavors blueprint?18:16
s3wongSumitNaiksatam: yes, I read through enikanorov 's bp before writing the workflow18:17
SumitNaiksatams3wong: nice18:17
bmelandes3wong: The service port seems to assume that an external port cannot be another neutron port, only something on a physical device.18:17
s3wongso it should work well with the flavor framework18:17
SumitNaiksatambmelande: good point, s3wong can you take note ^^^18:18
SumitNaiksatamthe next topic is related, so lets move on18:18
s3wongbmelande: sorry, that must be due to my poor writing (and lack of detail description). ExternalPort is something that does not belong to the tenant who requests the service18:18
SumitNaiksatam#topic Service insertion proposal update18:18
*** openstack changes topic to "Service insertion proposal update (Meeting topic: Networking Advanced Services)"18:18
SumitNaiksatamKanzhe: ?18:18
SumitNaiksatam: #link https://docs.google.com/document/d/1AlEockwk0Ir267U9uFDc-Q6vYsWiAcAoKtCJM0Jc5UI/edit#heading=h.v0wed816g3i118:18
s3wongso if you have a ServiceVM that is managed by the admin, for example, the tenant object still connects to it via the ExternalPort18:18
KanzheSumitNaiksatam: yes. It is the same doc that s3wong and I put together.18:19
s3wongso not limited by the physical / hardware device18:19
SumitNaiksatams3wong: thanks18:19
SumitNaiksatamKanzhe: ok good, any changes over the past week?18:19
KanzheservicePort is the main abstraction to express service Insertion.18:19
s3wongbmelande: will update doc to reflect that18:19
SumitNaiksatamKanzhe: ok good18:19
KanzheSumitNaiksatam: The main changes is about workflow.18:19
SumitNaiksatamKanzhe: what is the ETA for submitting this to gerrit18:20
SumitNaiksatam?18:20
Kanzhes3wong and I will convert to gerrit in the next day or two.18:20
SumitNaiksatamKanzhe: ok nice18:20
bmelandes3wong: Our use case is that service VM has a set of port (owned by special service tenant). Those ports are effectively trunk port. Multiple networks (in tenants owning the service instance) are trunked on the trunk port.18:20
SumitNaiksatamKanzhe: can you please very quicly summarize what is the change to workflow that you are indicating?18:20
s3wongSumitNaiksatam: the major change really is about not having admin specific objects, but relying on service agents to give us interface information18:21
KanzheThe main change is to clarify the integration with flavor BP18:21
SumitNaiksatams3wong, Kanzhe: ok18:21
SumitNaiksatamperhaps folks need to read through the doc18:21
SumitNaiksatambmelande: can you comment on the doc?18:21
gduanbmelande: Erik submitted a code review for trunk port18:21
s3wongbmelande: yes, that was the use case we talked about also at the ServiceVM meeting18:21
s3wongbmelande: with the absence of trunk port support, one way is the driver for CRS1000v would need to return an ExternalPort per each VLAN18:22
bmelandes3wong, SumitNaiksatam,gduan: yes will do, yes he did, yes thats the one we talked about18:22
SumitNaiksatambmelande: ok thanks18:23
regXboione thing that is not quite clear in the google doc18:23
SumitNaiksatamregXboi: sure, go ahead18:23
regXboiis overlay transport considered L2 or L3 for insertion mode18:23
regXboiI can argue both18:23
*** jcoufal has joined #openstack-meeting-318:24
s3wongregXboi: the insertion mode (Lx) depends on whether the service is inserted into a Neutron network or connected to a router18:24
regXboican we add that then?18:24
SumitNaiksatamregXboi: i would imagine that is a property of the network18:24
regXboithat makes it much cleaner18:24
regXboiand yes, then it becomes a property of the network18:24
s3wongregXboi: will clarify in the document. Thanks!18:25
SumitNaiksatams3wong Kanzhe: thanks!18:25
SumitNaiksatami know we are rushing here a bit18:25
SumitNaiksatam#topic Traffic Steering18:25
*** openstack changes topic to "Traffic Steering (Meeting topic: Networking Advanced Services)"18:25
SumitNaiksatamcgoncalves: over to you18:25
cgoncalves#link https://review.openstack.org/#/c/9247718:25
s3wongSumitNaiksatam: five minutes for traffic steering, service chaining, and open discussion18:26
SumitNaiksatamcgoncalves: thanks for submitting promptly18:26
s3wong:-)18:26
SumitNaiksatamand also for the pretty ascii! :-)18:26
cgoncalvesas most of you know I've submitted the proposal. there's the link ^18:26
SumitNaiksatams3wong: sure, why not! :-P18:26
cgoncalvesSumitNaiksatam: still struggling with the use case pics though18:26
SumitNaiksatams3wong: after all the hours we spent before18:26
SumitNaiksatamcgoncalves: pics?18:26
cgoncalvesSumitNaiksatam: https://docs.google.com/document/d/1Bk1e8-diE1VnzlbM8l479Mjx2vKliqdqC_3l5S56ITU/edit#heading=h.jpcx6ne3dl5018:27
SumitNaiksatamoh you mean inserting the figures for the use cases18:27
*** mestery has quit IRC18:27
SumitNaiksatamcgoncalves: dont worry about it18:27
cgoncalvesthis wekk I've been thinking on start developing this BP18:27
SumitNaiksatamperhaps a reference is good18:27
s3wongcgoncalves: sorry for our delay - with ServiceBase now having all the attachment information, perhaps there is something there you can leverage in this bp?18:27
regXboiin the BP one question18:27
cgoncalvesI'd like to hear from you on how do you think it would be best to implement it.18:28
regXboithe statement that the abstraction *can be leveraged* implies that there is more than one way to specify a service chain18:28
regXboiis that a good idea?18:28
mandeepregXboi: Yes18:28
SumitNaiksatamregXboi: there are different levels of abstraction18:28
mandeepregXboi: There are multi-function boxes that can not support full traffic streeing18:28
cgoncalvess3wong: will look again, sure18:28
mandeepregXboi: But they can honor the requirements of a chain18:29
SumitNaiksatamcgoncalves: thanks18:29
s3wongcgoncalves: great. Thanks!18:29
SumitNaiksatamcgoncalves: we will continue to discuss this in the summit18:29
SumitNaiksatamcgoncalves: i know you cannot make it, but we shepherd it18:29
regXboihaving more than one way to do something is adding complexity, so I have to ask if it is really necessary18:29
cgoncalvesSumitNaiksatam: ok, but note that I won't join you all though18:29
cgoncalvesSumitNaiksatam: ok18:29
s3wongcgoncalves: I trust that you and your team will be in Atlanta? perhaps we can meet and discuss?18:29
regXboithat's all18:29
SumitNaiksatammandeep regXboi: nice segue to the topic18:30
cgoncalvess3wong: we won't make it this time, sorry18:30
SumitNaiksatam#topic Service Chaining18:30
*** openstack changes topic to "Service Chaining (Meeting topic: Networking Advanced Services)"18:30
SumitNaiksatammandeep: please continue18:30
SumitNaiksatammandeep: i know you have dependency on the earlier items18:30
mandeepFollowing up on comments from regXboi18:30
* regXboi listens18:30
mandeepThe current proposal for service base, service insertion and servoce chaining18:31
SumitNaiksatamwe are going to go a few minutes over (hope thats fine with everyone)18:31
mandeepallow for a very complete model to be developed in future18:31
*** mestery has joined #openstack-meeting-318:31
mandeepBut we already have existing services that can provide services in a very common use case18:31
*** notmyname has quit IRC18:31
mandeepThat is "chaining multiple bump-in-the-wire services"18:32
*** notmyname_ has joined #openstack-meeting-318:32
mandeepThe intent of this proposal is to identify that use case (and it's context)18:32
mandeepand define the expectations on the semantics of that service18:32
*** notmyname_ is now known as notmyname18:32
regXboiso you envision this as being for L2 insertions?18:32
mandeepthat way, the service could be achieved by sterribg traffic between multiple services inserted in a network18:33
regXboimandeep: clarity - that implies that this is for L2 insertions and not for L3 insertions?18:33
mandeep(at L2 or L3), or by a multifunction service that can honor the chain semantics18:33
mandeepThe semantics are defined in terms of BITW model.18:34
mandeepThat is typically L218:34
mandeepBut the implementation may wrap it in L3 or any other tagging mechanims - the abstraction does not imply the implementation18:34
regXboiso, I ask because I didn't make the jump from port to L218:35
mandeepThe semantics need to be honoured, and the specification is of those semantics18:35
regXboiI read this as being applicable to ports on a router18:35
SumitNaiksatamregXboi: a lot of the questions you are asking are actually meant to be answered in teh service insertion blueprint18:36
mandeepregXboi: Actually you are correct. I was using L2 incorrectly18:36
regXboiSumitNaiksatam: it's likely, the topics tend to bleed together18:36
SumitNaiksatamregXboi: completely agree18:36
SumitNaiksatamregXboi: but at a high level, the thinking was that the service chain blueprint would leverage the service insertion and traffic steering abstractions provided to it18:37
mandeepregXboi: The intent is to define a semantic at usage/consumption of the service and not require orchestration/steering if your technology can not support it18:37
regXboimandeep: Understood, though I'm still concerned about having more than one way to accomplish something, but I'll put some more thought into nailing down the issues I foresee18:37
mandeepregXboi: But if it is available, that would probably be the simplest mapping18:37
regXboibecause if they aren't real, then there's no reason to worry18:38
regXboimandeep: agreed18:38
mandeepregXboi: OK, I will look into that as well18:38
SumitNaiksatammandeep: we will have the spec in gerrit by next week?18:38
SumitNaiksatammandeep: i know you have a dependency on the service insertion blueprint to land18:38
mandeepregXboi: They are real .. that is how for example the current FW service is provided (on the router port)18:38
mandeepSumitNaiksatam: Yes18:39
SumitNaiksatammandeep: great, thanks18:39
SumitNaiksatamregXboi mandeep: thanks for that discussion18:39
SumitNaiksatam#open discussion18:39
SumitNaiksatamwe are over time as usual18:39
regXboiyou mean #topic?18:39
mandeep:-018:39
SumitNaiksatamregXboi: yes18:39
SumitNaiksatami am getting restless18:39
mandeep:-)18:39
SumitNaiksatam#topic open discussion18:39
*** openstack changes topic to "open discussion (Meeting topic: Networking Advanced Services)"18:39
SumitNaiksatamanything else to discuss before we meet in person next week?18:40
s3wongan official announcement that we won't have meeting next week? :-)18:40
regXboiyes - I won't make ATL :(18:40
mandeepPerhaps, meet at the PoD?18:40
SumitNaiksatams3wong: yes thaks18:40
regXboiso will pick up again in two weeks18:40
SumitNaiksatam#announcement no meeting next week :-)18:40
cgoncalvess3wong: nooo! :-(18:41
mandeepregXboi: I will  be missing too this time :-(18:41
SumitNaiksatamregXboi: yes18:41
SumitNaiksatamwe will miss you both!18:41
SumitNaiksatamok thanks everyone (fwaas folks are waiting)18:41
SumitNaiksatamsee you in atlanta18:41
s3wongthanks!18:41
SumitNaiksatam#endmeeting18:41
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"18:41
openstackMeeting ended Wed May  7 18:41:44 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:41
openstackMinutes:        http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-05-07-17.31.html18:41
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-05-07-17.31.txt18:41
banixbye18:41
openstackLog:            http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-05-07-17.31.log.html18:41
SumitNaiksatamsafe travels18:41
cgoncalvesas I'm not attending sumit, I can still join you over audio/video conf if you think its best18:41
SumitNaiksatambye!18:41
regXboialoha18:41
*** regXboi has left #openstack-meeting-318:41
cgoncalvescya!18:41
SumitNaiksatamcgoncalves: yes sure, we will try18:42
*** pcm_ has left #openstack-meeting-318:42
*** rkukura has left #openstack-meeting-318:42
*** mandeep has left #openstack-meeting-318:42
*** bmelande has quit IRC18:42
*** Kanzhe has quit IRC18:42
SumitNaiksatamSridarK gduan beyounn there?18:42
gduanYes18:42
SridarKHi18:42
s3wongcgoncalves: perhaps, currently it is scheduled on Monday 10am EST18:42
s3wongEDT18:43
s3wongwe will try to get a video link if possible18:43
SumitNaiksatamok lets get started with FWaaS meeting18:43
SumitNaiksatam#startmeeting Networking FWaaS18:43
openstackMeeting started Wed May  7 18:43:54 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.18:43
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:43
*** openstack changes topic to " (Meeting topic: Networking FWaaS)"18:43
openstackThe meeting name has been set to 'networking_fwaas'18:43
SumitNaiksatamso we discussed the priorities over the last week18:44
*** pcm_ has joined #openstack-meeting-318:44
sballeSumitNaiksatam, I'll stay for this one :-)18:44
SumitNaiksatamsballe: sure, most welcome :-)18:44
sballeSumitNaiksatam, thx :)18:44
SumitNaiksatam#info etherpad for summit: https://etherpad.openstack.org/p/juno-fwaas18:45
SridarKSumitNaiksatam: have put in some basic stuff18:45
SumitNaiksatamSridarK: thanks much for the updates!18:45
SumitNaiksatam#topic Integration with Flavor Framework18:46
*** openstack changes topic to "Integration with Flavor Framework (Meeting topic: Networking FWaaS)"18:46
SridarKwe can update on the specific BP links shortly18:46
SumitNaiksatamgduan: you are going to take this up, or enikanorov will do it?18:46
SumitNaiksatami am guessing enikanorov is swamped18:46
enikanorovi think STF is still pending18:46
SumitNaiksatamenikanorov: i agree18:47
*** Swami has quit IRC18:47
enikanorovthat needs to be merged to start working with flavors integration18:47
SumitNaiksatamenikanorov: ok, so we dont have consensus on that?18:47
SridarKenikanorov: we will also have more discussion on this in ATL on STF ?18:47
SumitNaiksatamenikanorov: sorry, i forgot to bring it up in the adv services meeting!18:47
enikanorovi think we do. gduan: could you update the patch with new version?18:47
*** otherwiseguy has joined #openstack-meeting-318:47
enikanorovSridarK: i think i'll cover  it briefly on design track18:48
gduanenikanorov: you mean sync?18:48
SumitNaiksatamenikanorov: i believe from the last meeting, the PTL agreed to the STF direction?18:48
enikanorovgduan: i don't remember the most recent version, so did you remove provider attr from the public API?18:48
gduanenikanorov: ok. not yet. I will do that18:48
enikanorovgduan: ok, that was the most important change18:49
gduanenikanorov: sure. will do it today/tomorrow and submit spec too18:49
enikanorovSumitNaiksatam: i think Kyle agreed, but markmcclain's concerns need to be addressed18:49
enikanorov(if any)18:49
SumitNaiksatamenikanorov: ok, i think we need to get a move on18:49
SridarKSumitNaiksatam: one sec18:49
SumitNaiksatamenikanorov: if required lets have a separate meeting and plough through any objections18:50
SridarKSumitNaiksatam: i guess we keep the same BP18:50
SumitNaiksatamSridarK: we can keep the same bp, but we will need to create a bp spec in review18:50
enikanorovSumitNaiksatam: okay18:50
enikanorovSumitNaiksatam: i'll talk with Mark18:50
SridarKSumitNaiksatam: ok18:51
*** terryw has quit IRC18:51
SumitNaiksatamenikanorov: we can invite the PTL, markmcclain1 and whoever else is interested18:51
SumitNaiksatamenikanorov: thanks18:51
*** jamie_h has quit IRC18:51
SridarKSumitNaiksatam: this will be good18:51
SumitNaiksatamSridarK: good point to bring up from process perspective18:51
SumitNaiksatamso once the STF issue is settled, who is doing the flavor’s patch for FWaaS?18:52
*** ttrifonov is now known as ttrifonov_zZzz18:52
SumitNaiksatamok perhaps we need to get STF patch in first18:53
SumitNaiksatamgduan: you need to file a new bp for STF, right?18:53
SumitNaiksatamgduan: assumign we have thumbs up for using STF18:53
gduanSumitNaiksatam: just spec for review, right?18:53
SumitNaiksatamgduan: yeah18:53
gduanSumitNaiksatam: will do it today18:54
gduanSumitNaiksatam: but it will be very short18:54
SumitNaiksatamgduan: thanks!18:54
SumitNaiksatamgduan: yes sure18:54
SumitNaiksatamenikanorov: btw, is there a new spec for STF?18:54
SumitNaiksatamenikanorov: you mentioned changes earlier, where have those been made?18:54
enikanorovSumitNaiksatam: not yet, haven't managed to prepare it18:54
SumitNaiksatamenikanorov: ah ok18:54
*** MaxV has joined #openstack-meeting-318:54
SumitNaiksatamenikanorov: but you have a patch in review?18:55
enikanorovSumitNaiksatam: i meant the changes of gduan's patch18:55
SumitNaiksatamenikanorov: ok18:55
enikanorovwhere public STF attributes need to be removed18:55
SumitNaiksatamenikanorov: ah got it, to prepare it for flavors integration18:55
SumitNaiksatamgduan: so no dependency for you as far as this is concerned18:56
SumitNaiksatamso lets get the STF in first, and circle back to the flavors patch18:57
SumitNaiksatam#topic FWaaS Service Insertion18:57
*** openstack changes topic to "FWaaS Service Insertion (Meeting topic: Networking FWaaS)"18:57
SumitNaiksatamso we have to create a bp for this as well18:58
SumitNaiksatamand it will have a dependency on the service insertion stuff discussed earlier18:58
*** hareeshpc has quit IRC18:58
*** ttrifonov_zZzz is now known as ttrifonov18:58
SumitNaiksatamwe also need to check with kanzhe if he is planning to add support for this18:58
SumitNaiksatamin fwaas18:58
SumitNaiksatambut this is our priority for juno to be able to insertion on a specific router18:59
SridarKSumitNaiksatam: ok was just going to ask if that will only cover the base infrastructure or have a sample implementation18:59
SumitNaiksatam#action SumitNaiksatam to check with Kanzhe on service insertion support for fwaas18:59
SridarKSumitNaiksatam: If Kanzhe does that - we will get it for free :-)19:00
SumitNaiksatamSridarK: yeah that was my understanding :-)19:00
SridarKSumitNaiksatam: so we should not refer to the old BP on this in the ether pad - i will remove that19:00
SumitNaiksatamok19:01
SumitNaiksatamlet be there for now19:01
SridarKok19:01
SumitNaiksatamsince there is no insertion bp19:01
SridarKok got it19:01
SumitNaiksatamin fact let the old one be there, and we can add a second one19:01
SridarKok19:01
SumitNaiksatamit will help people to know the history19:01
SumitNaiksatamSridarK: thanks for bringing that up19:01
SridarKnp19:02
SumitNaiksatam#topic FWaaS Service Objects19:02
*** openstack changes topic to "FWaaS Service Objects (Meeting topic: Networking FWaaS)"19:02
SumitNaiksatambeyounn: we are on track for this?19:02
SumitNaiksatambeyounn: submit the bp in gerrit that is?19:02
SumitNaiksatamgduan: can you check with beyounn?19:03
SumitNaiksatamwe need the bp to be in gerrit before the summit, so that we can discuss19:03
SumitNaiksatam#topic FWaaS Zones19:04
*** openstack changes topic to "FWaaS Zones (Meeting topic: Networking FWaaS)"19:04
SumitNaiksatamSridarK: i know you have been busy with the critical bug19:04
SridarKSumitNaiksatam: working on the write up based on last weeks discussions19:04
SumitNaiksatamSridarK: ok19:05
SridarKwill have it gerrit in tne next day or two19:05
SumitNaiksatamSridarK: lets also keep an eye on the service insertion discussion since these are interpendent19:05
SumitNaiksatamSridarK: i would recommend first putting in google doc19:05
SridarKSumitNaiksatam: yes very much so - will indicate dependency on that19:05
SumitNaiksatamSridarK:  it might be faster and easier to draw diagrams19:06
SridarKSumitNaiksatam: ok that makes more sense19:06
SridarKwill do that19:06
SumitNaiksatamSridarK: you can then fill the gerrit template at leisure19:06
SridarKsounds good19:06
SumitNaiksatamSridarK: we want validate the proposal first19:06
SridarKok we can discuss first then19:07
SumitNaiksatamSridarK: i know we spent a lot of time earlier on this, but i still dont have a crisp idea in my mind19:07
SumitNaiksatamSridarK gduan: one question i have though, is it always possible to “infer” zones?19:07
SridarKSumitNaiksatam: ok and in any case there are the dependencies and that influences a lot of how we specify19:08
SridarKSumitNaiksatam: hmm! infer - i am not sure we can do that always19:08
SumitNaiksatammeaning if the particular firewall backend implementation always requires a zones configuration, can the driver map the neutron constructs to a zone?19:08
SumitNaiksatamSridarK: ok19:08
SumitNaiksatamSridarK: its ok if we cannot handle all the cases19:09
SridarKSumitNaiksatam: u are thinking of the default case kind of scenario ?19:09
SumitNaiksatamSridarK: yeah19:09
SridarKSumitNaiksatam: that i think we can do by having something like a any zone to any zone19:10
SumitNaiksatamSridarK: ah ok19:10
SumitNaiksatamSridarK: i was hoping a little more specific than that, but i myself dont have a clear idea in mind19:10
SumitNaiksatamSridarK:  so i am just loud thinking19:10
SridarKi probab did not say that very well but basically like a regular firewall19:10
SumitNaiksatamSridarK: ok19:11
SridarKSumitNaiksatam: will clarify that in the doc19:11
SumitNaiksatamSridarK: do we know if any of the vendor folks who use zones are going to be around for the discussion?19:11
SridarKSumitNaiksatam: not sure on that - i am trying to troll our mktg guys for some user scenarios that they can share19:12
SumitNaiksatamSridarK: :-)19:12
SumitNaiksatamSridarK: if they dont want it, we are off the hook?!? :-P19:12
SumitNaiksatammoving on19:13
SumitNaiksatam#topic FWaaS Ceilometer Requirements19:13
*** openstack changes topic to "FWaaS Ceilometer Requirements (Meeting topic: Networking FWaaS)"19:13
SridarKSumitNaiksatam: i think i need to rephrase my ask in that way - i am sure i will get a quick response :-)19:13
SumitNaiksatamSridarK: :-)19:13
SumitNaiksatamSridarK: is prad around?19:13
SumitNaiksatamyou have updated the etherpad with the requirements19:13
SridarKyes added the basic ones19:14
SumitNaiksatammy understanding was the same in speaking to him19:14
SridarKi will need to also reflect the usage - metrics that we can do19:14
SumitNaiksatamwho is filing the bp for this?19:14
SridarKor rather we dont have to do anything for that19:14
SridarKHe has a BP on the Ceilometer side19:14
SumitNaiksatamwill prad have the bandwidth to do it in neutron?19:15
SumitNaiksatamat least file the bp19:15
SridarKnot sure on that19:15
SridarKwill follow up on that19:15
SumitNaiksatami would rather prefer that the requirements are driven from ceilometer19:15
SumitNaiksatami mean someone from that team files the bp on the neutron side as well19:15
SridarKyes makes sense - will let him know and we can prioritize the implementation based on bandwidth19:16
SumitNaiksatami believe RajeshMohan mentioned he would have time to pursue this if needed19:16
SumitNaiksatamSridarK: thank19:16
SumitNaiksatams19:16
SridarKok cool19:16
SumitNaiksatam#topic Vendor drivers19:16
*** openstack changes topic to "Vendor drivers (Meeting topic: Networking FWaaS)"19:16
SumitNaiksatamgduan: there?19:17
SridarKHmm seems like gduan dropped off19:17
SridarKBut he did mention that they may be doing a refactor of the existing19:17
SridarKimpl19:17
SumitNaiksatamok, i wanted to track the bp19:18
SumitNaiksatamit needs to be added19:18
SumitNaiksatamI also see Cisco driver19:18
SumitNaiksatamwho is doing it?19:18
SumitNaiksatami mean who is creating the bp for it?19:18
SridarKYes i will file the BP and push for Gerrit review19:18
SumitNaiksatamSridarK:  ok good19:19
SridarKon implementation perhaps others will join in as well not clear19:19
SumitNaiksatamSridarK: yes, good, better to get help on that19:19
SumitNaiksatamSridarK: we will need you on core fwaas19:19
SridarKSumitNaiksatam: :-)19:19
SumitNaiksatamSridarK: though it should be made clear that blueprints expire at the end of the release cycle19:20
SumitNaiksatamat least thats my current understanding19:20
SridarKSumitNaiksatam: may need some vendor extensions on that BP will get ur thoughts on that offline19:20
SridarKSumitNaiksatam: ok19:20
*** Louis_ has joined #openstack-meeting-319:21
SumitNaiksatamSridarK:  ok sure19:21
SumitNaiksatam#topic open discussion19:21
*** openstack changes topic to "open discussion (Meeting topic: Networking FWaaS)"19:21
SumitNaiksatami think we will have our plates overflowing with the above in Juno19:21
SridarKSumitNaiksatam: yes i think Juno will be a tight release19:22
SumitNaiksatamso i think this is a good plan to be discussed in the summit19:22
SridarKlook fwd to that - it will be good to have something shipped in Juno19:22
SumitNaiksatamSridarK:  yeah i dont know how far we can get with the above19:22
SumitNaiksatami guess it all depends on the reviewer turn around!19:22
SridarKSumitNaiksatam: we will give it our best push19:23
SumitNaiksatamSridarK: absolutely (for a change) ! :-)19:23
SumitNaiksatamalso we have to go through two rounds of reviews19:23
SumitNaiksatamone for the bp and one for the code19:23
SridarKWith the BP reviews - it is good to get folks plugged in early and hopefully will help on the code reviews19:23
SumitNaiksatamhopefully the bp review wont take the entire cycle :-P19:23
SridarK:-)19:24
SumitNaiksatamalrighty lets wrap it!19:24
SridarKSumitNaiksatam: sounds good19:24
SumitNaiksatamanything else?19:24
SridarKno nothing19:24
SridarKsee u at ATL19:24
SridarKwill send u email on the zones doc19:24
SumitNaiksatamSridarK gduan beyounn sballe: thanks for joining, see you in ATL19:24
SumitNaiksatambye19:24
SumitNaiksatam#endmeeting19:25
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"19:25
openstackMeeting ended Wed May  7 19:25:01 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:25
SridarKbye19:25
openstackMinutes:        http://eavesdrop.openstack.org/meetings/networking_fwaas/2014/networking_fwaas.2014-05-07-18.43.html19:25
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/networking_fwaas/2014/networking_fwaas.2014-05-07-18.43.txt19:25
openstackLog:            http://eavesdrop.openstack.org/meetings/networking_fwaas/2014/networking_fwaas.2014-05-07-18.43.log.html19:25
sballeSumitNaiksatam, Definetly. Looking forward to ATL and to meeting you all in person19:25
SumitNaiksatamsballe: great, thanks, bye!19:26
sballebye19:26
*** pcm_ has left #openstack-meeting-319:26
*** Louis_ has quit IRC19:35
*** TravT has quit IRC19:40
*** nacim has joined #openstack-meeting-319:45
*** chuckC has joined #openstack-meeting-319:45
*** TravT has joined #openstack-meeting-319:46
*** emagana has quit IRC19:58
*** SumitNaiksatam has quit IRC19:59
*** jcoufal has quit IRC20:08
*** terryw has joined #openstack-meeting-320:12
*** otherwiseguy has quit IRC20:14
*** rm_work is now known as rm_work|away20:15
*** SumitNaiksatam has joined #openstack-meeting-320:18
*** iben_ has quit IRC20:19
*** shakamunyi has quit IRC20:27
*** devlaps has quit IRC20:30
*** julim has quit IRC20:33
*** mwagner_ has quit IRC20:39
*** terryw has quit IRC20:41
*** otherwiseguy has joined #openstack-meeting-320:55
*** shakamunyi has joined #openstack-meeting-320:56
*** shakamunyi has quit IRC21:07
*** devlaps has joined #openstack-meeting-321:07
*** devlaps has quit IRC21:12
*** lblanchard has quit IRC21:23
*** rm_work|away is now known as rm_work21:24
*** sballe has quit IRC21:24
*** lcheng_ has joined #openstack-meeting-321:25
*** lcheng_ has quit IRC21:29
*** peristeri has quit IRC21:32
*** emagana has joined #openstack-meeting-321:33
*** chuckC has quit IRC21:33
*** emagana has quit IRC21:33
*** emagana has joined #openstack-meeting-321:34
*** devlaps has joined #openstack-meeting-321:35
*** rand738 has quit IRC21:40
*** rand738 has joined #openstack-meeting-321:40
*** otherwiseguy has quit IRC21:41
*** shakamunyi has joined #openstack-meeting-321:41
*** otherwiseguy has joined #openstack-meeting-321:43
*** emagana has quit IRC21:49
*** emagana has joined #openstack-meeting-321:52
*** chuckC has joined #openstack-meeting-322:02
*** ttrifonov is now known as ttrifonov_zZzz22:07
*** chuckC has quit IRC22:07
*** otherwiseguy has quit IRC22:25
*** otherwiseguy has joined #openstack-meeting-322:35
*** s3wong has left #openstack-meeting-322:45
*** shakamunyi has quit IRC22:51
*** boris-42 has quit IRC22:57
*** boris-42 has joined #openstack-meeting-322:58
*** david-lyle has quit IRC22:59
*** gduan has quit IRC23:00
*** garyduan has joined #openstack-meeting-323:01
*** chuckC has joined #openstack-meeting-323:01
*** banix has quit IRC23:02
*** david-ly_ has joined #openstack-meeting-323:03
*** mwagner_ has joined #openstack-meeting-323:03
*** emagana has quit IRC23:04
*** overlayer has joined #openstack-meeting-323:12
*** overlayer has quit IRC23:14
*** otherwiseguy has quit IRC23:24
*** beyounn has quit IRC23:42
*** beyounn has joined #openstack-meeting-323:43
*** beyounn has quit IRC23:54
*** david-ly_ has quit IRC23:55

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