*** SumitNaiksatam has quit IRC | 00:08 | |
*** Sukhdev has joined #openstack-meeting-3 | 00:14 | |
*** devlaps has quit IRC | 00:20 | |
*** jaypipes has joined #openstack-meeting-3 | 00:23 | |
*** chuckC has quit IRC | 00:25 | |
*** SumitNaiksatam has joined #openstack-meeting-3 | 00:33 | |
*** SumitNaiksatam has quit IRC | 00:39 | |
*** yamahata has joined #openstack-meeting-3 | 00:42 | |
*** yamahata has quit IRC | 00:55 | |
*** notmyname has quit IRC | 01:03 | |
*** david-lyle has joined #openstack-meeting-3 | 01:03 | |
*** notmyname has joined #openstack-meeting-3 | 01:06 | |
*** alexpilotti has quit IRC | 01:11 | |
*** SumitNaiksatam has joined #openstack-meeting-3 | 01:13 | |
*** lcheng_ has quit IRC | 01:32 | |
*** banix has joined #openstack-meeting-3 | 01:40 | |
*** sankarshan is now known as sankarshan_away | 01:48 | |
*** Sukhdev_ has joined #openstack-meeting-3 | 01:50 | |
*** Sukhdev has quit IRC | 01:50 | |
*** Sukhdev has joined #openstack-meeting-3 | 01:52 | |
*** notmyname has quit IRC | 01:54 | |
*** notmyname has joined #openstack-meeting-3 | 01:54 | |
*** vkmc has quit IRC | 01:55 | |
*** Sukhdev_ has quit IRC | 01:55 | |
*** Sukhdev has quit IRC | 01:56 | |
*** david-lyle has quit IRC | 01:57 | |
*** alexpilotti has joined #openstack-meeting-3 | 02:07 | |
*** alexpilotti has quit IRC | 02:23 | |
*** banix has quit IRC | 02:27 | |
*** banix has joined #openstack-meeting-3 | 02:27 | |
*** sankarshan_away is now known as sankarshan | 02:37 | |
*** yamahata has joined #openstack-meeting-3 | 02:52 | |
*** amotoki has quit IRC | 03:14 | |
*** Sukhdev has joined #openstack-meeting-3 | 03:21 | |
*** banix has quit IRC | 03:21 | |
*** Sukhdev has joined #openstack-meeting-3 | 03:21 | |
*** chuckC has joined #openstack-meeting-3 | 03:30 | |
*** coolsvap|afk is now known as coolsvap | 03:34 | |
*** amotoki has joined #openstack-meeting-3 | 03:56 | |
*** sankarshan is now known as sankarshan_away | 04:06 | |
*** sankarshan_away is now known as sankarshan | 04:54 | |
*** Sukhdev has quit IRC | 05:21 | |
*** jcoufal has joined #openstack-meeting-3 | 05:33 | |
*** eghobo has joined #openstack-meeting-3 | 05:53 | |
*** eghobo has quit IRC | 05:54 | |
*** eghobo has joined #openstack-meeting-3 | 05:54 | |
*** mrunge has joined #openstack-meeting-3 | 06:56 | |
*** jcoufal has quit IRC | 07:00 | |
*** eghobo has quit IRC | 07:04 | |
*** lsmola has joined #openstack-meeting-3 | 07:09 | |
*** lsmola2 has joined #openstack-meeting-3 | 07:17 | |
*** MaxV has joined #openstack-meeting-3 | 07:21 | |
*** ttrifonov_zZzz is now known as ttrifonov | 07:27 | |
*** lsmola2 has quit IRC | 07:27 | |
*** jcoufal has joined #openstack-meeting-3 | 07:37 | |
*** safchain has joined #openstack-meeting-3 | 07:54 | |
*** MaxV has quit IRC | 07:54 | |
*** MaxV has joined #openstack-meeting-3 | 08:03 | |
*** nacim has joined #openstack-meeting-3 | 08:11 | |
*** jamie_h has joined #openstack-meeting-3 | 08:35 | |
*** nacim has quit IRC | 08:54 | |
*** nacim has joined #openstack-meeting-3 | 09:07 | |
*** overlayer has joined #openstack-meeting-3 | 09:23 | |
*** coolsvap is now known as coolsvap|afk | 09:30 | |
*** coolsvap|afk is now known as coolsvap | 09:58 | |
*** overlayer has quit IRC | 10:04 | |
*** safchain has quit IRC | 10:08 | |
*** overlayer has joined #openstack-meeting-3 | 10:11 | |
*** enykeev has quit IRC | 10:17 | |
*** enykeev has joined #openstack-meeting-3 | 10:21 | |
*** yamahata has quit IRC | 10:43 | |
*** overlayer has quit IRC | 10:47 | |
*** overlayer has joined #openstack-meeting-3 | 10:48 | |
*** overlayer has quit IRC | 10:53 | |
*** overlayer has joined #openstack-meeting-3 | 10:53 | |
*** coolsvap is now known as coolsvap|afk | 10:54 | |
*** jcoufal has quit IRC | 10:54 | |
*** jcoufal has joined #openstack-meeting-3 | 10:56 | |
*** overlayer_ has joined #openstack-meeting-3 | 11:00 | |
*** overlayer has quit IRC | 11:01 | |
*** overlayer_ has quit IRC | 11:13 | |
*** nacim has quit IRC | 11:16 | |
*** sankarshan is now known as sankarshan_away | 11:46 | |
*** amotoki has quit IRC | 11:59 | |
*** overlayer has joined #openstack-meeting-3 | 12:01 | |
*** d0ugal_ has joined #openstack-meeting-3 | 12:06 | |
*** d0ugal_ has quit IRC | 12:09 | |
*** mwagner_ has quit IRC | 12:09 | |
*** yamahata has joined #openstack-meeting-3 | 12:28 | |
*** yamahata has quit IRC | 12:33 | |
*** sankarshan_away is now known as sankarshan | 12:39 | |
*** peristeri has joined #openstack-meeting-3 | 12:40 | |
*** lblanchard has joined #openstack-meeting-3 | 12:45 | |
*** banix has joined #openstack-meeting-3 | 12:50 | |
*** nacim has joined #openstack-meeting-3 | 12:54 | |
*** banix has quit IRC | 13: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 coolsvap | 13:07 | |
*** julim has joined #openstack-meeting-3 | 13: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 IRC | 13:33 | |
*** overlayer has quit IRC | 13:37 | |
*** alexpilotti has joined #openstack-meeting-3 | 13:37 | |
*** overlayer has joined #openstack-meeting-3 | 13:38 | |
*** safchain has joined #openstack-meeting-3 | 13:41 | |
*** mwagner_ has joined #openstack-meeting-3 | 13:54 | |
*** overlayer has quit IRC | 14:00 | |
*** markmcclain has joined #openstack-meeting-3 | 14:05 | |
*** jpomero has joined #openstack-meeting-3 | 14:06 | |
*** markmcclain1 has joined #openstack-meeting-3 | 14:08 | |
*** markmcclain has quit IRC | 14:10 | |
*** jpomero has quit IRC | 14:12 | |
*** edleafe- has quit IRC | 14:12 | |
*** edleafe has joined #openstack-meeting-3 | 14:13 | |
*** jpomero has joined #openstack-meeting-3 | 14:15 | |
*** shakamunyi has joined #openstack-meeting-3 | 14:16 | |
*** d0ugal has quit IRC | 14:34 | |
*** d0ugal has joined #openstack-meeting-3 | 14:47 | |
*** d0ugal has quit IRC | 14:47 | |
*** d0ugal has joined #openstack-meeting-3 | 14:47 | |
*** cjellick has quit IRC | 14:53 | |
*** cjellick has joined #openstack-meeting-3 | 14:58 | |
*** cjellick has quit IRC | 15:07 | |
*** cjellick has joined #openstack-meeting-3 | 15:07 | |
*** banix has joined #openstack-meeting-3 | 15:08 | |
*** david-lyle has joined #openstack-meeting-3 | 15:15 | |
*** jcoufal has quit IRC | 15:20 | |
*** shakamunyi has quit IRC | 15:20 | |
*** shakamunyi has joined #openstack-meeting-3 | 15:23 | |
*** emagana has joined #openstack-meeting-3 | 15:36 | |
*** mrunge has quit IRC | 15:42 | |
*** eghobo has joined #openstack-meeting-3 | 15:48 | |
*** Sukhdev has joined #openstack-meeting-3 | 15:50 | |
*** nacim has quit IRC | 15:52 | |
*** lsmola has quit IRC | 15:58 | |
*** lcheng_ has joined #openstack-meeting-3 | 16:04 | |
*** tjones has joined #openstack-meeting-3 | 16:21 | |
*** devlaps has joined #openstack-meeting-3 | 16:25 | |
tjones | #startmeeting NovaBugScrub | 16:30 |
---|---|---|
openstack | Meeting 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 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:30 |
*** openstack changes topic to " (Meeting topic: NovaBugScrub)" | 16:30 | |
openstack | The meeting name has been set to 'novabugscrub' | 16:30 |
tjones | anyone here today? | 16:31 |
tjones | ok - we'll i've doing finished the tagging so i'll go ahead and end the meeting. nothing controversial there | 16:34 |
tjones | #endmeeting | 16:34 |
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 16:34 | |
openstack | Meeting ended Wed May 7 16:34:53 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:34 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/novabugscrub/2014/novabugscrub.2014-05-07-16.30.html | 16:34 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/novabugscrub/2014/novabugscrub.2014-05-07-16.30.txt | 16:34 |
openstack | Log: http://eavesdrop.openstack.org/meetings/novabugscrub/2014/novabugscrub.2014-05-07-16.30.log.html | 16:34 |
*** coolsvap is now known as coolsvap|afk | 16:46 | |
*** tjones has left #openstack-meeting-3 | 16:47 | |
*** MaxV has quit IRC | 17:07 | |
*** safchain has quit IRC | 17:11 | |
*** rkukura has joined #openstack-meeting-3 | 17:12 | |
*** lcheng_ has quit IRC | 17:20 | |
*** pcm_ has joined #openstack-meeting-3 | 17:29 | |
*** regXboi has joined #openstack-meeting-3 | 17:29 | |
*** SridarK has joined #openstack-meeting-3 | 17:30 | |
*** s3wong has joined #openstack-meeting-3 | 17:30 | |
SumitNaiksatam | hi Neutrons! | 17:30 |
s3wong | Hello | 17:30 |
banix | Policy Fenatics :) | 17:30 |
s3wong | banix: this is advanced service, no? :-) | 17:30 |
SridarK | Hi All :-) | 17:30 |
pcm_ | hi | 17:30 |
banix | sorry wrong meeting | 17:30 |
enikanorov | hi | 17:30 |
banix | s3wong: got too excited :) | 17:31 |
cgoncalves | hi all | 17:31 |
SumitNaiksatam | banix: we welcome all! ;-P | 17:31 |
*** sballe has joined #openstack-meeting-3 | 17:31 | |
SumitNaiksatam | banix: especially policy fanatics | 17:31 |
*** Kanzhe has joined #openstack-meeting-3 | 17:31 | |
SridarK | banix: is like an electron | 17:31 |
banix | :) | 17:31 |
SumitNaiksatam | ok i think we have crical mass | 17:31 |
SumitNaiksatam | lets get started | 17:31 |
SumitNaiksatam | #startmeeting Networking Advanced Services | 17:31 |
openstack | Meeting 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 |
openstack | Useful 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 IRC | 17:32 | |
openstack | The meeting name has been set to 'networking_advanced_services' | 17:32 |
SumitNaiksatam | Meeting agenda: #link https://wiki.openstack.org/wiki/Meetings/AdvancedServices | 17:32 |
rkukura | hi | 17:32 |
SumitNaiksatam | #link https://wiki.openstack.org/wiki/Neutron/AdvancedServices | 17:32 |
sballe | hi. | 17:32 |
SumitNaiksatam | sballe: hi | 17:32 |
SumitNaiksatam | #topic Neutron Advanced Services' Common Framework | 17:33 |
*** openstack changes topic to "Neutron Advanced Services' Common Framework (Meeting topic: Networking Advanced Services)" | 17:33 | |
SumitNaiksatam | #link https://review.openstack.org/#/c/92200 | 17:33 |
SumitNaiksatam | per our discussion during the past several weeks, and direction from the PTL, the above umbrella blueprint was posted | 17:33 |
SumitNaiksatam | hope there were no surprises with regards to the content in that spec, it was based on the consensus until last week | 17:34 |
SumitNaiksatam | if you get a chance a please review | 17:34 |
banix | SumitNaiksatam: do we need to get this approved, or it simple stands to bring other pieces together? | 17:34 |
SumitNaiksatam | thoughts/questions? | 17:34 |
SumitNaiksatam | banix: ah good point | 17:34 |
sballe | SumitNaiksatam, Is this proposal a step closer towards having a clean integration between Neutron core and the Advanced Services? | 17:34 |
gduan | Hi | 17:34 |
SumitNaiksatam | my understanding is that it probably needs to get approved | 17:34 |
SumitNaiksatam | however, we need to get all the dependent blueprints in | 17:35 |
SumitNaiksatam | we will follow up on the individual components in the agenda of the meeting | 17:35 |
sballe | and interface? or is it more a workflow type of thing e.g. service lyfe cycle | 17:35 |
SumitNaiksatam | sballe: its both | 17:35 |
SumitNaiksatam | banix: does that answer | 17:36 |
sballe | SumitNaiksatam, perfect. thx | 17:36 |
banix | SumitNaiksatam: yes thanks | 17:36 |
s3wong | SumitNaiksatam: well, at the very least, service definition isn't being pointed to the reference link in the doc | 17:36 |
SumitNaiksatam | sballe: there is some amount of integration, though not perfect | 17:36 |
*** TravT has joined #openstack-meeting-3 | 17:36 | |
SumitNaiksatam | sballe: this is a step in the process of organic evolution | 17:36 |
SumitNaiksatam | s3wong: ?? | 17:37 |
s3wong | SumitNaiksatam: [3] isn't properly pointing to the document with service base definition | 17:37 |
SumitNaiksatam | s3wong: do you have a new link/ | 17:37 |
s3wong | SumitNaiksatam: same service insertion document | 17:37 |
*** Swami has joined #openstack-meeting-3 | 17:37 | |
Swami | hi | 17:38 |
SumitNaiksatam | s3wong: ok, need to check | 17:38 |
SumitNaiksatam | s3wong: will update accordingly | 17:38 |
emagana | hi there.. bit late! | 17:38 |
SumitNaiksatam | most of those references are place holders though, waiting for the gerrit blueprints to be filed | 17:38 |
SumitNaiksatam | sballe: does that answer your question? | 17:38 |
s3wong | SumitNaiksatam: good | 17:38 |
SumitNaiksatam | hi to all those who just joined | 17:39 |
SumitNaiksatam | ok moving on | 17:39 |
SumitNaiksatam | so since we have a high level plan, i propose that we henceforth start tracking in individual item | 17:40 |
sballe | SumitNaiksatam, yes. I am looking at the BP now. I would like to see somewhere that we identify the need for a clean integration with Neutron | 17:40 |
SumitNaiksatam | sballe: the whole discussion iis in the context of Neutron itself | 17:41 |
SumitNaiksatam | sballe: so there are multiple touch points with neutron | 17:41 |
SumitNaiksatam | sballe: or rather with the rest of neutron | 17:41 |
sballe | SumitNaiksatam, I understand but I am told that the LBaaS for example manipulate the Neutron tables directly. There should be an API for that | 17:41 |
SumitNaiksatam | sballe: in every component that is identified | 17:41 |
enikanorov | sballe: why? lbaas is a part of neutron, it has direct access to the DB | 17:42 |
SumitNaiksatam | sballe: sure, that might have been an implementation short cut | 17:42 |
enikanorov | the api is LbaaS DB plugin itself | 17:42 |
enikanorov | no additional layer is needed | 17:42 |
SumitNaiksatam | enikanorov: yes, i agree those are local calls | 17:42 |
SumitNaiksatam | enikanorov: not REST api calls | 17:43 |
*** chuckC has quit IRC | 17:43 | |
SumitNaiksatam | enikanorov: perhaps what sballe is indicating is that services should access neutron through clean interfaces rather than manipulating the db tables | 17:43 |
sballe | SumitNaiksatam, 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 |
SumitNaiksatam | if indeed that is happening | 17:43 |
sballe | SumitNaiksatam, Yes that was my point. Thx | 17:44 |
SumitNaiksatam | sballe: agreed | 17:44 |
SumitNaiksatam | enikanorov: sound okay, i think we are on the same page, right? | 17:44 |
sballe | SumitNaiksatam, Can we add this item to the BP? | 17:44 |
enikanorov | SumitNaiksatam: i'm actually not sure :) | 17:45 |
SumitNaiksatam | sballe: yes sure, please also feel free to comment | 17:45 |
SumitNaiksatam | enikanorov: ok :-) | 17:45 |
enikanorov | while services are plugins which are within the same process accessing the same DB... | 17:45 |
sballe | SumitNaiksatam, Will do. | 17:45 |
enikanorov | i wonder what additional interfaces are needed to work with it? | 17:45 |
enikanorov | anyway, we can discuss it offline | 17:46 |
SumitNaiksatam | enikanorov: hypothetical example - you might not want lbaas code to maniplulate neutron “port” table directly | 17:46 |
sballe | this was mention by markmcclain1 and mestery at some point when we talked about the neutron/LBaaS connection | 17:46 |
SumitNaiksatam | sballe: is that what you had in mind? | 17:47 |
enikanorov | SumitNaiksatam: well.. we're all gentlemen, we trust other's code, right? | 17:47 |
sballe | SumitNaiksatam, yes along these lines | 17:47 |
enikanorov | or otherwise we would be writing java | 17:47 |
SumitNaiksatam | enikanorov: ha | 17:47 |
cgoncalves | enikanorov: :D | 17:47 |
SumitNaiksatam | ok we are getting philosophical, so we move on | 17:47 |
SumitNaiksatam | this discussion on the drinks table in atlanta :-) | 17:47 |
enikanorov | sure :) | 17:48 |
sballe | perfect. count me in :-) | 17:48 |
SumitNaiksatam | so my earlier question to the team, regarding tracking progress on the individual components listed in the bp (going forward in this meeting) | 17:48 |
SumitNaiksatam | sound okay? | 17:48 |
enikanorov | sure | 17:48 |
sballe | yes | 17:48 |
enikanorov | i can update on flavor fw | 17:48 |
s3wong | Yes | 17:48 |
cgoncalves | SumitNaiksatam: yes, please continue | 17:48 |
SumitNaiksatam | that way we can have some milestones and dates | 17:48 |
SumitNaiksatam | good | 17:49 |
SumitNaiksatam | so start with our favorite topic | 17:49 |
SumitNaiksatam | or rather flavor | 17:49 |
banix | yes | 17:49 |
s3wong | "flavor-ite" | 17:49 |
enikanorov | ok | 17:49 |
SumitNaiksatam | #topic Flavors framework | 17:49 |
*** openstack changes topic to "Flavors framework (Meeting topic: Networking Advanced Services)" | 17:49 | |
SumitNaiksatam | enikanorov: you are the cook! | 17:49 |
SumitNaiksatam | er…chef | 17:49 |
enikanorov | so... i think https://review.openstack.org/#/c/90070/ is in good shape and pretty much everything about the framework itself is covered | 17:50 |
enikanorov | so please review | 17:50 |
SumitNaiksatam | enikanorov: ok | 17:50 |
SumitNaiksatam | questions for enikanorov? | 17:50 |
regXboi | well, I'm going to jump in and say that going up the stack - it looks fine | 17:50 |
enikanorov | however we've found an issue that we didn't though on much | 17:50 |
SumitNaiksatam | enikanorov: my apologies, i have been behind | 17:50 |
regXboi | going down the stack, I have questions | 17:50 |
enikanorov | it's not a blocker for the framework itself | 17:50 |
*** Sukhdev has quit IRC | 17:50 | |
SumitNaiksatam | regXboi: sure, whats down the stack | 17:51 |
enikanorov | but it's something that should be solved for the integration between flavors and particular service | 17:51 |
banix | welcome regXboi | 17:51 |
s3wong | enikanorov: what is the issue? | 17:51 |
regXboi | what I don't see is a way for someone to pick between different implementations of services by the same provider | 17:51 |
enikanorov | i'm giving an example: | 17:51 |
enikanorov | user creates a service using some flavor | 17:51 |
SumitNaiksatam | enikanorov: please go ahead | 17:51 |
enikanorov | and then tries to create/update some part of it, which chosen implementation doesn't support | 17:52 |
enikanorov | so user gets an 'unsupported' error | 17:52 |
enikanorov | the issue is that user might not know from the flavor that this feature is not supported | 17:52 |
enikanorov | particular example: | 17:52 |
enikanorov | user creates haproxy loadbalancer | 17:52 |
*** otherwiseguy has joined #openstack-meeting-3 | 17:53 | |
enikanorov | then it tries to add PING health monitor that haproxy doesn't support | 17:53 |
*** hareeshpc has joined #openstack-meeting-3 | 17:53 | |
enikanorov | ... | 17:53 |
pcm_ | enikanorov: seems to tie in w/my concerns about vendor validation, and client capabilities | 17:53 |
enikanorov | right not it's not very clear to me how to indicate that to a user prior trying and failing | 17:53 |
s3wong | enikanorov: 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 |
enikanorov | one option is to have detailed description of flavors | 17:54 |
enikanorov | s3wong: it's actually bad | 17:54 |
enikanorov | s3wong: because you don't know the provider now | 17:54 |
enikanorov | s3wong: how can you know what you should change to get this damn feature working? | 17:54 |
s3wong | enikanorov: on the flip side, if every supported features need a tag, that makes the flavor language too bloated | 17:55 |
enikanorov | so looks like flavors need to include lots of stuff, or otherwise such failures will be very confusing for a user | 17:55 |
banix | shouldnt you have specified this requirement when you asked for the service ? | 17:55 |
enikanorov | s3wong: that's true as well | 17:55 |
gduan | even a vendor driver supports PING server, the function might work a little differently from vendor to vendor | 17:55 |
enikanorov | banix: right, but should I require each and every kind of feature? | 17:55 |
enikanorov | gduan: yes. | 17:56 |
s3wong | gduan: good point | 17:56 |
enikanorov | so this might be solved by 'get_capabilities' call | 17:56 |
SumitNaiksatam | enikanorov: so we had discussed earlier about different types of attributes | 17:56 |
enikanorov | but we need such method before flavor fw choses the provider | 17:56 |
SumitNaiksatam | or capabilitites | 17:56 |
SumitNaiksatam | there are those which are common to all “types” of services | 17:56 |
pcm_ | enikanorov: In my L3 vendor plugins I have a BP on that. How client knows vendor capabilities | 17:57 |
*** mestery has joined #openstack-meeting-3 | 17:57 | |
pcm_ | enikanorov: Though not sure how to best handle that. | 17:57 |
SumitNaiksatam | then there are those that are common “within" a service type | 17:57 |
SumitNaiksatam | and then there are those which are more specific to drivers | 17:57 |
s3wong | very soon, for more complicated services, get_capabilities will return several pages worth of information | 17:57 |
enikanorov | so, framework itself is flexible enough to handle this problem in various ways | 17:57 |
enikanorov | but when it comes to integration - it better to be solved in some convenient way | 17:58 |
banix | s3wong: which is fine. no? | 17:58 |
gduan | I doubt there is an 'accurate' description of capability | 17:58 |
enikanorov | we don't want to bloat flavors for cloud ops, but we also don't wan't to confuse users | 17:58 |
*** hareeshpc has quit IRC | 17:58 | |
SumitNaiksatam | enikanorov: hence the suggestion to have different categories of capabilitites | 17:58 |
s3wong | banix: user would have to sniff through the list of capabilities before a user can choose - like a product catalog | 17:58 |
*** mandeep has joined #openstack-meeting-3 | 17:59 | |
enikanorov | SumitNaiksatam: yeah, the categories are just strings, and it's all about string matching | 17:59 |
SumitNaiksatam | enikanorov: i am suggesting separate API calls perhaps | 17:59 |
enikanorov | so it's more about a general way of how we handle it | 17:59 |
SumitNaiksatam | enikanorov: so you can say, get_service_capabilities(), get_servcice_type_capabilities(), get_service_driver_capabilities() | 18:00 |
enikanorov | for the particular example above i suggest it is solved by adding 'healthmonitor:PING' capability | 18:00 |
s3wong | and 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 |
SumitNaiksatam | something like that, those api names might be off | 18:00 |
enikanorov | s3wong: 'how' can i pick that | 18:00 |
enikanorov | SumitNaiksatam: yes, that's what we will need | 18:01 |
pcm_ | Should this BP address this issue? https://review.openstack.org/#/c/89366/1/specs/juno/l3-svcs-vendor-client-cap.rst | 18:01 |
enikanorov | so my concern is | 18:01 |
Kanzhe | enikanorov: then every capability should be scoped with service type. | 18:01 |
*** mestery_ has joined #openstack-meeting-3 | 18:01 | |
enikanorov | flavor maps to several providers | 18:01 |
gduan | enikanorov: who should be define these capability ist? | 18:01 |
*** bmelande has joined #openstack-meeting-3 | 18:02 | |
gduan | sorry typos | 18:02 |
enikanorov | and then we need precise flavor to let user work with particular feature | 18:02 |
enikanorov | gduan: driver's authors | 18:02 |
SridarK | enikanorov: i think beyond the simple cases, the user could pick based on the vendor and the particular implementation for esoteric needs | 18:02 |
SumitNaiksatam | Kanzhe: there can be common capabilities (base capabilities) and then those that are specific to types | 18:03 |
enikanorov | SridarK: yes, but the main goal of Flavors to hide providers from the user | 18:03 |
s3wong | enikanorov: 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-3 | 18:03 | |
banix | enikanorov: exactly; so we are getting distanced from that | 18:04 |
enikanorov | s3wong: it's done on 1) driver side 2) by cloud operator | 18:04 |
gduan | s3wong: yes, the superset of all possible capability names | 18:04 |
Kanzhe | SumitNaiksatam: sure. Scope can be used to indicate common, type specific, etc. | 18:04 |
SridarK | enikanorov: i agree but i am afraid that we will have something unwieldy on the more complex cases | 18:04 |
gduan | s3wong: then vendor drivers claim they support the subset | 18:04 |
enikanorov | SridarK: choosing provider is also supported by the flavors | 18:04 |
SumitNaiksatam | ok, we need to move on | 18:04 |
s3wong | enikanorov: 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 |
enikanorov | so, so i'll finish | 18:04 |
*** mestery has quit IRC | 18:04 | |
SumitNaiksatam | enikanorov: sure | 18:04 |
enikanorov | the issue i've told about is for integration | 18:04 |
banix | SumitNaiksatam: regXboi had a question | 18:05 |
enikanorov | the framework itself is fine | 18:05 |
enikanorov | so please review and approve :) | 18:05 |
regXboi | so the framework is intended to hide provider from user - i get that | 18:05 |
s3wong | enikanorov: yes, I agreed. The framework and workflow is fine | 18:05 |
Kanzhe | enikanorov: why not just provider:model for flavor. and refer to manuals for detail capabilities. :-) | 18:05 |
SumitNaiksatam | yes, all please review, and we need make move forward on this topic | 18:05 |
regXboi | what I don't see is what about specification of a particular instance of a service from a provider | 18:05 |
pcm_ | Can folks look at my BP, as it tries to address caps to client? | 18:05 |
regXboi | that may not be flavor, but I'm not seeing it anywhere | 18:06 |
SumitNaiksatam | pcm_: sure, thanks | 18:06 |
s3wong | Kanzhe: I think that's what enikanorov wants to avoid, exposing provider brand/product names | 18:06 |
enikanorov | regXboi: explain? | 18:06 |
*** mestery_ is now known as mestery | 18:06 | |
SumitNaiksatam | pcm_’s blueprint: https://review.openstack.org/#/c/89366/1/specs/juno/l3-svcs-vendor-client-cap.rst | 18:06 |
regXboi | so flavor is intended to hide provider from user | 18:06 |
enikanorov | yep | 18:06 |
pcm_ | SumitNaiksatam: thanks. If it fits, we can use it as a forum for discussion of this part of it. | 18:06 |
s3wong | pcm_: will take a look, sure | 18:06 |
regXboi | what happens in the case where a provider has multiple instances of a service available | 18:06 |
banix | pcm_: will look; thanks. | 18:06 |
regXboi | and wants to allow a user to specify the instance | 18:07 |
enikanorov | regXboi: multiple backends you mean. | 18:07 |
enikanorov | regXboi: provider doesn't allow user to specify particular backend | 18:07 |
regXboi | um | 18:07 |
enikanorov | but it could be sheduled with flavors | 18:07 |
s3wong | regXboi: the scheduling algorithm takes care of that, tenants don't get to choose a particular backend | 18:07 |
enikanorov | say, flavor has a tag: 'connetctions':'unlimited' | 18:07 |
regXboi | that's an assumption I don't quite agree with, but ok | 18:07 |
enikanorov | and that will hint sheduler to place an instance to a performance backend | 18:08 |
enikanorov | regXboi: user is not in control of backends, neither provider, nor particular appliance/device | 18:08 |
enikanorov | regXboi: that's whole point of abstraction | 18:08 |
regXboi | ok, I'll let it drop | 18:08 |
SumitNaiksatam | we can have f2f discussion in the summit as well | 18:09 |
SumitNaiksatam | enikanorov: ok to move on? | 18:09 |
enikanorov | SumitNaiksatam: sure, even more then once i guess | 18:09 |
enikanorov | SumitNaiksatam: that's it from my side if there are no more questions | 18:09 |
*** terryw has joined #openstack-meeting-3 | 18:10 | |
s3wong | enikanorov: flavor only get 1/3 of a design session :-) | 18:10 |
SumitNaiksatam | enikanorov: great thanks, that discussion was a full course meal for this meeting! | 18:10 |
SumitNaiksatam | s3wong: we can do more | 18:10 |
SumitNaiksatam | flavor will be part of the adv services common framework discussion | 18:10 |
SumitNaiksatam | so we will get 2/3rd of the time to cover the adv services topics | 18:11 |
SumitNaiksatam | enikanorov: sound okay? | 18:11 |
enikanorov | yes | 18:11 |
SumitNaiksatam | i dont know what the third topic is about | 18:11 |
SumitNaiksatam | i was hoping that proposer would have joined thid forum | 18:11 |
SumitNaiksatam | so we could have had a coherent plan/strategy | 18:11 |
SumitNaiksatam | anyway | 18:11 |
SumitNaiksatam | #topic Base service definition | 18:11 |
*** openstack changes topic to "Base service definition (Meeting topic: Networking Advanced Services)" | 18:11 | |
SumitNaiksatam | s3wong: over to you | 18:12 |
s3wong | #link https://docs.google.com/document/d/1AlEockwk0Ir267U9uFDc-Q6vYsWiAcAoKtCJM0Jc5UI/edit#heading=h.v0wed816g3i1 | 18:12 |
SumitNaiksatam | this captures any changes we need to make to base service defintion to support insertion and chaining (and also flavors) | 18:12 |
s3wong | Kanzhe and I decided to merge the two topics into one document | 18:12 |
SumitNaiksatam | s3wong: ok | 18:12 |
*** otherwiseguy has quit IRC | 18:12 | |
SumitNaiksatam | so we are going to have one gerrit spec for this? | 18:13 |
s3wong | SumitNaiksatam: yes | 18:13 |
SumitNaiksatam | ok | 18:13 |
SumitNaiksatam | s3wong: can you quickly highlight the changes to the base service definition? | 18:13 |
Kanzhe | s3wong: The two topics are service base class definition and service insertion. | 18:13 |
mandeep | SumitNaiksatam: My understanding was that we will have a different gerrit blueprint for chanining | 18:14 |
SumitNaiksatam | mandeep: yes thats a different spec | 18:14 |
mandeep | SumitNaiksatam: I am OK either way, just asking for clarification | 18:14 |
mandeep | SumitNaiksatam: OK | 18:14 |
regXboi | is the list of service ports in service base class ordered or not? | 18:14 |
SumitNaiksatam | mandeep: we will come to that in the agenda | 18:14 |
s3wong | The ServiceBase object is used to maintain the connection mapping of where a service is being inserted | 18:14 |
SumitNaiksatam | mandeep: sorry i think i forgot to add that | 18:14 |
SumitNaiksatam | s3wong: please proceed | 18:14 |
s3wong | regXboi: No - order will be determined by ... the service chaining framework | 18:14 |
regXboi | s3wong: thanks | 18:14 |
Kanzhe | regXboi: servicePorts are not order. This is not serviceChaining. | 18:15 |
regXboi | wasn't thinking of service chaining | 18:15 |
regXboi | was thinking of abstraction | 18:15 |
Kanzhe | regXboi: Do you see a need for ordering? | 18:15 |
SumitNaiksatam | mandeep: added | 18:15 |
regXboi | not sure - was asking | 18:15 |
regXboi | need to think about it some more | 18:15 |
mandeep | SumitNaiksatam: Thanks | 18:15 |
s3wong | I 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 enough | 18:16 |
SumitNaiksatam | s3wong: ok, does this reconcile with the flavors blueprint? | 18:16 |
s3wong | SumitNaiksatam: yes, I read through enikanorov 's bp before writing the workflow | 18:17 |
SumitNaiksatam | s3wong: nice | 18:17 |
bmelande | s3wong: The service port seems to assume that an external port cannot be another neutron port, only something on a physical device. | 18:17 |
s3wong | so it should work well with the flavor framework | 18:17 |
SumitNaiksatam | bmelande: good point, s3wong can you take note ^^^ | 18:18 |
SumitNaiksatam | the next topic is related, so lets move on | 18:18 |
s3wong | bmelande: 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 service | 18:18 |
SumitNaiksatam | #topic Service insertion proposal update | 18:18 |
*** openstack changes topic to "Service insertion proposal update (Meeting topic: Networking Advanced Services)" | 18:18 | |
SumitNaiksatam | Kanzhe: ? | 18:18 |
SumitNaiksatam | : #link https://docs.google.com/document/d/1AlEockwk0Ir267U9uFDc-Q6vYsWiAcAoKtCJM0Jc5UI/edit#heading=h.v0wed816g3i1 | 18:18 |
s3wong | so if you have a ServiceVM that is managed by the admin, for example, the tenant object still connects to it via the ExternalPort | 18:18 |
Kanzhe | SumitNaiksatam: yes. It is the same doc that s3wong and I put together. | 18:19 |
s3wong | so not limited by the physical / hardware device | 18:19 |
SumitNaiksatam | s3wong: thanks | 18:19 |
SumitNaiksatam | Kanzhe: ok good, any changes over the past week? | 18:19 |
Kanzhe | servicePort is the main abstraction to express service Insertion. | 18:19 |
s3wong | bmelande: will update doc to reflect that | 18:19 |
SumitNaiksatam | Kanzhe: ok good | 18:19 |
Kanzhe | SumitNaiksatam: The main changes is about workflow. | 18:19 |
SumitNaiksatam | Kanzhe: what is the ETA for submitting this to gerrit | 18:20 |
SumitNaiksatam | ? | 18:20 |
Kanzhe | s3wong and I will convert to gerrit in the next day or two. | 18:20 |
SumitNaiksatam | Kanzhe: ok nice | 18:20 |
bmelande | s3wong: 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 |
SumitNaiksatam | Kanzhe: can you please very quicly summarize what is the change to workflow that you are indicating? | 18:20 |
s3wong | SumitNaiksatam: the major change really is about not having admin specific objects, but relying on service agents to give us interface information | 18:21 |
Kanzhe | The main change is to clarify the integration with flavor BP | 18:21 |
SumitNaiksatam | s3wong, Kanzhe: ok | 18:21 |
SumitNaiksatam | perhaps folks need to read through the doc | 18:21 |
SumitNaiksatam | bmelande: can you comment on the doc? | 18:21 |
gduan | bmelande: Erik submitted a code review for trunk port | 18:21 |
s3wong | bmelande: yes, that was the use case we talked about also at the ServiceVM meeting | 18:21 |
s3wong | bmelande: with the absence of trunk port support, one way is the driver for CRS1000v would need to return an ExternalPort per each VLAN | 18:22 |
bmelande | s3wong, SumitNaiksatam,gduan: yes will do, yes he did, yes thats the one we talked about | 18:22 |
SumitNaiksatam | bmelande: ok thanks | 18:23 |
regXboi | one thing that is not quite clear in the google doc | 18:23 |
SumitNaiksatam | regXboi: sure, go ahead | 18:23 |
regXboi | is overlay transport considered L2 or L3 for insertion mode | 18:23 |
regXboi | I can argue both | 18:23 |
*** jcoufal has joined #openstack-meeting-3 | 18:24 | |
s3wong | regXboi: the insertion mode (Lx) depends on whether the service is inserted into a Neutron network or connected to a router | 18:24 |
regXboi | can we add that then? | 18:24 |
SumitNaiksatam | regXboi: i would imagine that is a property of the network | 18:24 |
regXboi | that makes it much cleaner | 18:24 |
regXboi | and yes, then it becomes a property of the network | 18:24 |
s3wong | regXboi: will clarify in the document. Thanks! | 18:25 |
SumitNaiksatam | s3wong Kanzhe: thanks! | 18:25 |
SumitNaiksatam | i know we are rushing here a bit | 18:25 |
SumitNaiksatam | #topic Traffic Steering | 18:25 |
*** openstack changes topic to "Traffic Steering (Meeting topic: Networking Advanced Services)" | 18:25 | |
SumitNaiksatam | cgoncalves: over to you | 18:25 |
cgoncalves | #link https://review.openstack.org/#/c/92477 | 18:25 |
s3wong | SumitNaiksatam: five minutes for traffic steering, service chaining, and open discussion | 18:26 |
SumitNaiksatam | cgoncalves: thanks for submitting promptly | 18:26 |
s3wong | :-) | 18:26 |
SumitNaiksatam | and also for the pretty ascii! :-) | 18:26 |
cgoncalves | as most of you know I've submitted the proposal. there's the link ^ | 18:26 |
SumitNaiksatam | s3wong: sure, why not! :-P | 18:26 |
cgoncalves | SumitNaiksatam: still struggling with the use case pics though | 18:26 |
SumitNaiksatam | s3wong: after all the hours we spent before | 18:26 |
SumitNaiksatam | cgoncalves: pics? | 18:26 |
cgoncalves | SumitNaiksatam: https://docs.google.com/document/d/1Bk1e8-diE1VnzlbM8l479Mjx2vKliqdqC_3l5S56ITU/edit#heading=h.jpcx6ne3dl50 | 18:27 |
SumitNaiksatam | oh you mean inserting the figures for the use cases | 18:27 |
*** mestery has quit IRC | 18:27 | |
SumitNaiksatam | cgoncalves: dont worry about it | 18:27 |
cgoncalves | this wekk I've been thinking on start developing this BP | 18:27 |
SumitNaiksatam | perhaps a reference is good | 18:27 |
s3wong | cgoncalves: 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 |
regXboi | in the BP one question | 18:27 |
cgoncalves | I'd like to hear from you on how do you think it would be best to implement it. | 18:28 |
regXboi | the statement that the abstraction *can be leveraged* implies that there is more than one way to specify a service chain | 18:28 |
regXboi | is that a good idea? | 18:28 |
mandeep | regXboi: Yes | 18:28 |
SumitNaiksatam | regXboi: there are different levels of abstraction | 18:28 |
mandeep | regXboi: There are multi-function boxes that can not support full traffic streeing | 18:28 |
cgoncalves | s3wong: will look again, sure | 18:28 |
mandeep | regXboi: But they can honor the requirements of a chain | 18:29 |
SumitNaiksatam | cgoncalves: thanks | 18:29 |
s3wong | cgoncalves: great. Thanks! | 18:29 |
SumitNaiksatam | cgoncalves: we will continue to discuss this in the summit | 18:29 |
SumitNaiksatam | cgoncalves: i know you cannot make it, but we shepherd it | 18:29 |
regXboi | having more than one way to do something is adding complexity, so I have to ask if it is really necessary | 18:29 |
cgoncalves | SumitNaiksatam: ok, but note that I won't join you all though | 18:29 |
cgoncalves | SumitNaiksatam: ok | 18:29 |
s3wong | cgoncalves: I trust that you and your team will be in Atlanta? perhaps we can meet and discuss? | 18:29 |
regXboi | that's all | 18:29 |
SumitNaiksatam | mandeep regXboi: nice segue to the topic | 18:30 |
cgoncalves | s3wong: we won't make it this time, sorry | 18:30 |
SumitNaiksatam | #topic Service Chaining | 18:30 |
*** openstack changes topic to "Service Chaining (Meeting topic: Networking Advanced Services)" | 18:30 | |
SumitNaiksatam | mandeep: please continue | 18:30 |
SumitNaiksatam | mandeep: i know you have dependency on the earlier items | 18:30 |
mandeep | Following up on comments from regXboi | 18:30 |
* regXboi listens | 18:30 | |
mandeep | The current proposal for service base, service insertion and servoce chaining | 18:31 |
SumitNaiksatam | we are going to go a few minutes over (hope thats fine with everyone) | 18:31 |
mandeep | allow for a very complete model to be developed in future | 18:31 |
*** mestery has joined #openstack-meeting-3 | 18:31 | |
mandeep | But we already have existing services that can provide services in a very common use case | 18:31 |
*** notmyname has quit IRC | 18:31 | |
mandeep | That is "chaining multiple bump-in-the-wire services" | 18:32 |
*** notmyname_ has joined #openstack-meeting-3 | 18:32 | |
mandeep | The intent of this proposal is to identify that use case (and it's context) | 18:32 |
mandeep | and define the expectations on the semantics of that service | 18:32 |
*** notmyname_ is now known as notmyname | 18:32 | |
regXboi | so you envision this as being for L2 insertions? | 18:32 |
mandeep | that way, the service could be achieved by sterribg traffic between multiple services inserted in a network | 18:33 |
regXboi | mandeep: 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 semantics | 18:33 |
mandeep | The semantics are defined in terms of BITW model. | 18:34 |
mandeep | That is typically L2 | 18:34 |
mandeep | But the implementation may wrap it in L3 or any other tagging mechanims - the abstraction does not imply the implementation | 18:34 |
regXboi | so, I ask because I didn't make the jump from port to L2 | 18:35 |
mandeep | The semantics need to be honoured, and the specification is of those semantics | 18:35 |
regXboi | I read this as being applicable to ports on a router | 18:35 |
SumitNaiksatam | regXboi: a lot of the questions you are asking are actually meant to be answered in teh service insertion blueprint | 18:36 |
mandeep | regXboi: Actually you are correct. I was using L2 incorrectly | 18:36 |
regXboi | SumitNaiksatam: it's likely, the topics tend to bleed together | 18:36 |
SumitNaiksatam | regXboi: completely agree | 18:36 |
SumitNaiksatam | regXboi: but at a high level, the thinking was that the service chain blueprint would leverage the service insertion and traffic steering abstractions provided to it | 18:37 |
mandeep | regXboi: The intent is to define a semantic at usage/consumption of the service and not require orchestration/steering if your technology can not support it | 18:37 |
regXboi | mandeep: 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 foresee | 18:37 |
mandeep | regXboi: But if it is available, that would probably be the simplest mapping | 18:37 |
regXboi | because if they aren't real, then there's no reason to worry | 18:38 |
regXboi | mandeep: agreed | 18:38 |
mandeep | regXboi: OK, I will look into that as well | 18:38 |
SumitNaiksatam | mandeep: we will have the spec in gerrit by next week? | 18:38 |
SumitNaiksatam | mandeep: i know you have a dependency on the service insertion blueprint to land | 18:38 |
mandeep | regXboi: They are real .. that is how for example the current FW service is provided (on the router port) | 18:38 |
mandeep | SumitNaiksatam: Yes | 18:39 |
SumitNaiksatam | mandeep: great, thanks | 18:39 |
SumitNaiksatam | regXboi mandeep: thanks for that discussion | 18:39 |
SumitNaiksatam | #open discussion | 18:39 |
SumitNaiksatam | we are over time as usual | 18:39 |
regXboi | you mean #topic? | 18:39 |
mandeep | :-0 | 18:39 |
SumitNaiksatam | regXboi: yes | 18:39 |
SumitNaiksatam | i am getting restless | 18:39 |
mandeep | :-) | 18:39 |
SumitNaiksatam | #topic open discussion | 18:39 |
*** openstack changes topic to "open discussion (Meeting topic: Networking Advanced Services)" | 18:39 | |
SumitNaiksatam | anything else to discuss before we meet in person next week? | 18:40 |
s3wong | an official announcement that we won't have meeting next week? :-) | 18:40 |
regXboi | yes - I won't make ATL :( | 18:40 |
mandeep | Perhaps, meet at the PoD? | 18:40 |
SumitNaiksatam | s3wong: yes thaks | 18:40 |
regXboi | so will pick up again in two weeks | 18:40 |
SumitNaiksatam | #announcement no meeting next week :-) | 18:40 |
cgoncalves | s3wong: nooo! :-( | 18:41 |
mandeep | regXboi: I will be missing too this time :-( | 18:41 |
SumitNaiksatam | regXboi: yes | 18:41 |
SumitNaiksatam | we will miss you both! | 18:41 |
SumitNaiksatam | ok thanks everyone (fwaas folks are waiting) | 18:41 |
SumitNaiksatam | see you in atlanta | 18:41 |
s3wong | thanks! | 18:41 |
SumitNaiksatam | #endmeeting | 18:41 |
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 18:41 | |
openstack | Meeting ended Wed May 7 18:41:44 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:41 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-05-07-17.31.html | 18:41 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-05-07-17.31.txt | 18:41 |
banix | bye | 18:41 |
openstack | Log: http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-05-07-17.31.log.html | 18:41 |
SumitNaiksatam | safe travels | 18:41 |
cgoncalves | as I'm not attending sumit, I can still join you over audio/video conf if you think its best | 18:41 |
SumitNaiksatam | bye! | 18:41 |
regXboi | aloha | 18:41 |
*** regXboi has left #openstack-meeting-3 | 18:41 | |
cgoncalves | cya! | 18:41 |
SumitNaiksatam | cgoncalves: yes sure, we will try | 18:42 |
*** pcm_ has left #openstack-meeting-3 | 18:42 | |
*** rkukura has left #openstack-meeting-3 | 18:42 | |
*** mandeep has left #openstack-meeting-3 | 18:42 | |
*** bmelande has quit IRC | 18:42 | |
*** Kanzhe has quit IRC | 18:42 | |
SumitNaiksatam | SridarK gduan beyounn there? | 18:42 |
gduan | Yes | 18:42 |
SridarK | Hi | 18:42 |
s3wong | cgoncalves: perhaps, currently it is scheduled on Monday 10am EST | 18:42 |
s3wong | EDT | 18:43 |
s3wong | we will try to get a video link if possible | 18:43 |
SumitNaiksatam | ok lets get started with FWaaS meeting | 18:43 |
SumitNaiksatam | #startmeeting Networking FWaaS | 18:43 |
openstack | Meeting 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 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 18:43 |
*** openstack changes topic to " (Meeting topic: Networking FWaaS)" | 18:43 | |
openstack | The meeting name has been set to 'networking_fwaas' | 18:43 |
SumitNaiksatam | so we discussed the priorities over the last week | 18:44 |
*** pcm_ has joined #openstack-meeting-3 | 18:44 | |
sballe | SumitNaiksatam, I'll stay for this one :-) | 18:44 |
SumitNaiksatam | sballe: sure, most welcome :-) | 18:44 |
sballe | SumitNaiksatam, thx :) | 18:44 |
SumitNaiksatam | #info etherpad for summit: https://etherpad.openstack.org/p/juno-fwaas | 18:45 |
SridarK | SumitNaiksatam: have put in some basic stuff | 18:45 |
SumitNaiksatam | SridarK: thanks much for the updates! | 18:45 |
SumitNaiksatam | #topic Integration with Flavor Framework | 18:46 |
*** openstack changes topic to "Integration with Flavor Framework (Meeting topic: Networking FWaaS)" | 18:46 | |
SridarK | we can update on the specific BP links shortly | 18:46 |
SumitNaiksatam | gduan: you are going to take this up, or enikanorov will do it? | 18:46 |
SumitNaiksatam | i am guessing enikanorov is swamped | 18:46 |
enikanorov | i think STF is still pending | 18:46 |
SumitNaiksatam | enikanorov: i agree | 18:47 |
*** Swami has quit IRC | 18:47 | |
enikanorov | that needs to be merged to start working with flavors integration | 18:47 |
SumitNaiksatam | enikanorov: ok, so we dont have consensus on that? | 18:47 |
SridarK | enikanorov: we will also have more discussion on this in ATL on STF ? | 18:47 |
SumitNaiksatam | enikanorov: sorry, i forgot to bring it up in the adv services meeting! | 18:47 |
enikanorov | i think we do. gduan: could you update the patch with new version? | 18:47 |
*** otherwiseguy has joined #openstack-meeting-3 | 18:47 | |
enikanorov | SridarK: i think i'll cover it briefly on design track | 18:48 |
gduan | enikanorov: you mean sync? | 18:48 |
SumitNaiksatam | enikanorov: i believe from the last meeting, the PTL agreed to the STF direction? | 18:48 |
enikanorov | gduan: i don't remember the most recent version, so did you remove provider attr from the public API? | 18:48 |
gduan | enikanorov: ok. not yet. I will do that | 18:48 |
enikanorov | gduan: ok, that was the most important change | 18:49 |
gduan | enikanorov: sure. will do it today/tomorrow and submit spec too | 18:49 |
enikanorov | SumitNaiksatam: i think Kyle agreed, but markmcclain's concerns need to be addressed | 18:49 |
enikanorov | (if any) | 18:49 |
SumitNaiksatam | enikanorov: ok, i think we need to get a move on | 18:49 |
SridarK | SumitNaiksatam: one sec | 18:49 |
SumitNaiksatam | enikanorov: if required lets have a separate meeting and plough through any objections | 18:50 |
SridarK | SumitNaiksatam: i guess we keep the same BP | 18:50 |
SumitNaiksatam | SridarK: we can keep the same bp, but we will need to create a bp spec in review | 18:50 |
enikanorov | SumitNaiksatam: okay | 18:50 |
enikanorov | SumitNaiksatam: i'll talk with Mark | 18:50 |
SridarK | SumitNaiksatam: ok | 18:51 |
*** terryw has quit IRC | 18:51 | |
SumitNaiksatam | enikanorov: we can invite the PTL, markmcclain1 and whoever else is interested | 18:51 |
SumitNaiksatam | enikanorov: thanks | 18:51 |
*** jamie_h has quit IRC | 18:51 | |
SridarK | SumitNaiksatam: this will be good | 18:51 |
SumitNaiksatam | SridarK: good point to bring up from process perspective | 18:51 |
SumitNaiksatam | so once the STF issue is settled, who is doing the flavor’s patch for FWaaS? | 18:52 |
*** ttrifonov is now known as ttrifonov_zZzz | 18:52 | |
SumitNaiksatam | ok perhaps we need to get STF patch in first | 18:53 |
SumitNaiksatam | gduan: you need to file a new bp for STF, right? | 18:53 |
SumitNaiksatam | gduan: assumign we have thumbs up for using STF | 18:53 |
gduan | SumitNaiksatam: just spec for review, right? | 18:53 |
SumitNaiksatam | gduan: yeah | 18:53 |
gduan | SumitNaiksatam: will do it today | 18:54 |
gduan | SumitNaiksatam: but it will be very short | 18:54 |
SumitNaiksatam | gduan: thanks! | 18:54 |
SumitNaiksatam | gduan: yes sure | 18:54 |
SumitNaiksatam | enikanorov: btw, is there a new spec for STF? | 18:54 |
SumitNaiksatam | enikanorov: you mentioned changes earlier, where have those been made? | 18:54 |
enikanorov | SumitNaiksatam: not yet, haven't managed to prepare it | 18:54 |
SumitNaiksatam | enikanorov: ah ok | 18:54 |
*** MaxV has joined #openstack-meeting-3 | 18:54 | |
SumitNaiksatam | enikanorov: but you have a patch in review? | 18:55 |
enikanorov | SumitNaiksatam: i meant the changes of gduan's patch | 18:55 |
SumitNaiksatam | enikanorov: ok | 18:55 |
enikanorov | where public STF attributes need to be removed | 18:55 |
SumitNaiksatam | enikanorov: ah got it, to prepare it for flavors integration | 18:55 |
SumitNaiksatam | gduan: so no dependency for you as far as this is concerned | 18:56 |
SumitNaiksatam | so lets get the STF in first, and circle back to the flavors patch | 18:57 |
SumitNaiksatam | #topic FWaaS Service Insertion | 18:57 |
*** openstack changes topic to "FWaaS Service Insertion (Meeting topic: Networking FWaaS)" | 18:57 | |
SumitNaiksatam | so we have to create a bp for this as well | 18:58 |
SumitNaiksatam | and it will have a dependency on the service insertion stuff discussed earlier | 18:58 |
*** hareeshpc has quit IRC | 18:58 | |
*** ttrifonov_zZzz is now known as ttrifonov | 18:58 | |
SumitNaiksatam | we also need to check with kanzhe if he is planning to add support for this | 18:58 |
SumitNaiksatam | in fwaas | 18:58 |
SumitNaiksatam | but this is our priority for juno to be able to insertion on a specific router | 18:59 |
SridarK | SumitNaiksatam: ok was just going to ask if that will only cover the base infrastructure or have a sample implementation | 18:59 |
SumitNaiksatam | #action SumitNaiksatam to check with Kanzhe on service insertion support for fwaas | 18:59 |
SridarK | SumitNaiksatam: If Kanzhe does that - we will get it for free :-) | 19:00 |
SumitNaiksatam | SridarK: yeah that was my understanding :-) | 19:00 |
SridarK | SumitNaiksatam: so we should not refer to the old BP on this in the ether pad - i will remove that | 19:00 |
SumitNaiksatam | ok | 19:01 |
SumitNaiksatam | let be there for now | 19:01 |
SridarK | ok | 19:01 |
SumitNaiksatam | since there is no insertion bp | 19:01 |
SridarK | ok got it | 19:01 |
SumitNaiksatam | in fact let the old one be there, and we can add a second one | 19:01 |
SridarK | ok | 19:01 |
SumitNaiksatam | it will help people to know the history | 19:01 |
SumitNaiksatam | SridarK: thanks for bringing that up | 19:01 |
SridarK | np | 19:02 |
SumitNaiksatam | #topic FWaaS Service Objects | 19:02 |
*** openstack changes topic to "FWaaS Service Objects (Meeting topic: Networking FWaaS)" | 19:02 | |
SumitNaiksatam | beyounn: we are on track for this? | 19:02 |
SumitNaiksatam | beyounn: submit the bp in gerrit that is? | 19:02 |
SumitNaiksatam | gduan: can you check with beyounn? | 19:03 |
SumitNaiksatam | we need the bp to be in gerrit before the summit, so that we can discuss | 19:03 |
SumitNaiksatam | #topic FWaaS Zones | 19:04 |
*** openstack changes topic to "FWaaS Zones (Meeting topic: Networking FWaaS)" | 19:04 | |
SumitNaiksatam | SridarK: i know you have been busy with the critical bug | 19:04 |
SridarK | SumitNaiksatam: working on the write up based on last weeks discussions | 19:04 |
SumitNaiksatam | SridarK: ok | 19:05 |
SridarK | will have it gerrit in tne next day or two | 19:05 |
SumitNaiksatam | SridarK: lets also keep an eye on the service insertion discussion since these are interpendent | 19:05 |
SumitNaiksatam | SridarK: i would recommend first putting in google doc | 19:05 |
SridarK | SumitNaiksatam: yes very much so - will indicate dependency on that | 19:05 |
SumitNaiksatam | SridarK: it might be faster and easier to draw diagrams | 19:06 |
SridarK | SumitNaiksatam: ok that makes more sense | 19:06 |
SridarK | will do that | 19:06 |
SumitNaiksatam | SridarK: you can then fill the gerrit template at leisure | 19:06 |
SridarK | sounds good | 19:06 |
SumitNaiksatam | SridarK: we want validate the proposal first | 19:06 |
SridarK | ok we can discuss first then | 19:07 |
SumitNaiksatam | SridarK: i know we spent a lot of time earlier on this, but i still dont have a crisp idea in my mind | 19:07 |
SumitNaiksatam | SridarK gduan: one question i have though, is it always possible to “infer” zones? | 19:07 |
SridarK | SumitNaiksatam: ok and in any case there are the dependencies and that influences a lot of how we specify | 19:08 |
SridarK | SumitNaiksatam: hmm! infer - i am not sure we can do that always | 19:08 |
SumitNaiksatam | meaning if the particular firewall backend implementation always requires a zones configuration, can the driver map the neutron constructs to a zone? | 19:08 |
SumitNaiksatam | SridarK: ok | 19:08 |
SumitNaiksatam | SridarK: its ok if we cannot handle all the cases | 19:09 |
SridarK | SumitNaiksatam: u are thinking of the default case kind of scenario ? | 19:09 |
SumitNaiksatam | SridarK: yeah | 19:09 |
SridarK | SumitNaiksatam: that i think we can do by having something like a any zone to any zone | 19:10 |
SumitNaiksatam | SridarK: ah ok | 19:10 |
SumitNaiksatam | SridarK: i was hoping a little more specific than that, but i myself dont have a clear idea in mind | 19:10 |
SumitNaiksatam | SridarK: so i am just loud thinking | 19:10 |
SridarK | i probab did not say that very well but basically like a regular firewall | 19:10 |
SumitNaiksatam | SridarK: ok | 19:11 |
SridarK | SumitNaiksatam: will clarify that in the doc | 19:11 |
SumitNaiksatam | SridarK: do we know if any of the vendor folks who use zones are going to be around for the discussion? | 19:11 |
SridarK | SumitNaiksatam: not sure on that - i am trying to troll our mktg guys for some user scenarios that they can share | 19:12 |
SumitNaiksatam | SridarK: :-) | 19:12 |
SumitNaiksatam | SridarK: if they dont want it, we are off the hook?!? :-P | 19:12 |
SumitNaiksatam | moving on | 19:13 |
SumitNaiksatam | #topic FWaaS Ceilometer Requirements | 19:13 |
*** openstack changes topic to "FWaaS Ceilometer Requirements (Meeting topic: Networking FWaaS)" | 19:13 | |
SridarK | SumitNaiksatam: i think i need to rephrase my ask in that way - i am sure i will get a quick response :-) | 19:13 |
SumitNaiksatam | SridarK: :-) | 19:13 |
SumitNaiksatam | SridarK: is prad around? | 19:13 |
SumitNaiksatam | you have updated the etherpad with the requirements | 19:13 |
SridarK | yes added the basic ones | 19:14 |
SumitNaiksatam | my understanding was the same in speaking to him | 19:14 |
SridarK | i will need to also reflect the usage - metrics that we can do | 19:14 |
SumitNaiksatam | who is filing the bp for this? | 19:14 |
SridarK | or rather we dont have to do anything for that | 19:14 |
SridarK | He has a BP on the Ceilometer side | 19:14 |
SumitNaiksatam | will prad have the bandwidth to do it in neutron? | 19:15 |
SumitNaiksatam | at least file the bp | 19:15 |
SridarK | not sure on that | 19:15 |
SridarK | will follow up on that | 19:15 |
SumitNaiksatam | i would rather prefer that the requirements are driven from ceilometer | 19:15 |
SumitNaiksatam | i mean someone from that team files the bp on the neutron side as well | 19:15 |
SridarK | yes makes sense - will let him know and we can prioritize the implementation based on bandwidth | 19:16 |
SumitNaiksatam | i believe RajeshMohan mentioned he would have time to pursue this if needed | 19:16 |
SumitNaiksatam | SridarK: thank | 19:16 |
SumitNaiksatam | s | 19:16 |
SridarK | ok cool | 19:16 |
SumitNaiksatam | #topic Vendor drivers | 19:16 |
*** openstack changes topic to "Vendor drivers (Meeting topic: Networking FWaaS)" | 19:16 | |
SumitNaiksatam | gduan: there? | 19:17 |
SridarK | Hmm seems like gduan dropped off | 19:17 |
SridarK | But he did mention that they may be doing a refactor of the existing | 19:17 |
SridarK | impl | 19:17 |
SumitNaiksatam | ok, i wanted to track the bp | 19:18 |
SumitNaiksatam | it needs to be added | 19:18 |
SumitNaiksatam | I also see Cisco driver | 19:18 |
SumitNaiksatam | who is doing it? | 19:18 |
SumitNaiksatam | i mean who is creating the bp for it? | 19:18 |
SridarK | Yes i will file the BP and push for Gerrit review | 19:18 |
SumitNaiksatam | SridarK: ok good | 19:19 |
SridarK | on implementation perhaps others will join in as well not clear | 19:19 |
SumitNaiksatam | SridarK: yes, good, better to get help on that | 19:19 |
SumitNaiksatam | SridarK: we will need you on core fwaas | 19:19 |
SridarK | SumitNaiksatam: :-) | 19:19 |
SumitNaiksatam | SridarK: though it should be made clear that blueprints expire at the end of the release cycle | 19:20 |
SumitNaiksatam | at least thats my current understanding | 19:20 |
SridarK | SumitNaiksatam: may need some vendor extensions on that BP will get ur thoughts on that offline | 19:20 |
SridarK | SumitNaiksatam: ok | 19:20 |
*** Louis_ has joined #openstack-meeting-3 | 19:21 | |
SumitNaiksatam | SridarK: ok sure | 19:21 |
SumitNaiksatam | #topic open discussion | 19:21 |
*** openstack changes topic to "open discussion (Meeting topic: Networking FWaaS)" | 19:21 | |
SumitNaiksatam | i think we will have our plates overflowing with the above in Juno | 19:21 |
SridarK | SumitNaiksatam: yes i think Juno will be a tight release | 19:22 |
SumitNaiksatam | so i think this is a good plan to be discussed in the summit | 19:22 |
SridarK | look fwd to that - it will be good to have something shipped in Juno | 19:22 |
SumitNaiksatam | SridarK: yeah i dont know how far we can get with the above | 19:22 |
SumitNaiksatam | i guess it all depends on the reviewer turn around! | 19:22 |
SridarK | SumitNaiksatam: we will give it our best push | 19:23 |
SumitNaiksatam | SridarK: absolutely (for a change) ! :-) | 19:23 |
SumitNaiksatam | also we have to go through two rounds of reviews | 19:23 |
SumitNaiksatam | one for the bp and one for the code | 19:23 |
SridarK | With the BP reviews - it is good to get folks plugged in early and hopefully will help on the code reviews | 19:23 |
SumitNaiksatam | hopefully the bp review wont take the entire cycle :-P | 19:23 |
SridarK | :-) | 19:24 |
SumitNaiksatam | alrighty lets wrap it! | 19:24 |
SridarK | SumitNaiksatam: sounds good | 19:24 |
SumitNaiksatam | anything else? | 19:24 |
SridarK | no nothing | 19:24 |
SridarK | see u at ATL | 19:24 |
SridarK | will send u email on the zones doc | 19:24 |
SumitNaiksatam | SridarK gduan beyounn sballe: thanks for joining, see you in ATL | 19:24 |
SumitNaiksatam | bye | 19:24 |
SumitNaiksatam | #endmeeting | 19:25 |
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 19:25 | |
openstack | Meeting ended Wed May 7 19:25:01 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 19:25 |
SridarK | bye | 19:25 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/networking_fwaas/2014/networking_fwaas.2014-05-07-18.43.html | 19:25 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/networking_fwaas/2014/networking_fwaas.2014-05-07-18.43.txt | 19:25 |
openstack | Log: http://eavesdrop.openstack.org/meetings/networking_fwaas/2014/networking_fwaas.2014-05-07-18.43.log.html | 19:25 |
sballe | SumitNaiksatam, Definetly. Looking forward to ATL and to meeting you all in person | 19:25 |
SumitNaiksatam | sballe: great, thanks, bye! | 19:26 |
sballe | bye | 19:26 |
*** pcm_ has left #openstack-meeting-3 | 19:26 | |
*** Louis_ has quit IRC | 19:35 | |
*** TravT has quit IRC | 19:40 | |
*** nacim has joined #openstack-meeting-3 | 19:45 | |
*** chuckC has joined #openstack-meeting-3 | 19:45 | |
*** TravT has joined #openstack-meeting-3 | 19:46 | |
*** emagana has quit IRC | 19:58 | |
*** SumitNaiksatam has quit IRC | 19:59 | |
*** jcoufal has quit IRC | 20:08 | |
*** terryw has joined #openstack-meeting-3 | 20:12 | |
*** otherwiseguy has quit IRC | 20:14 | |
*** rm_work is now known as rm_work|away | 20:15 | |
*** SumitNaiksatam has joined #openstack-meeting-3 | 20:18 | |
*** iben_ has quit IRC | 20:19 | |
*** shakamunyi has quit IRC | 20:27 | |
*** devlaps has quit IRC | 20:30 | |
*** julim has quit IRC | 20:33 | |
*** mwagner_ has quit IRC | 20:39 | |
*** terryw has quit IRC | 20:41 | |
*** otherwiseguy has joined #openstack-meeting-3 | 20:55 | |
*** shakamunyi has joined #openstack-meeting-3 | 20:56 | |
*** shakamunyi has quit IRC | 21:07 | |
*** devlaps has joined #openstack-meeting-3 | 21:07 | |
*** devlaps has quit IRC | 21:12 | |
*** lblanchard has quit IRC | 21:23 | |
*** rm_work|away is now known as rm_work | 21:24 | |
*** sballe has quit IRC | 21:24 | |
*** lcheng_ has joined #openstack-meeting-3 | 21:25 | |
*** lcheng_ has quit IRC | 21:29 | |
*** peristeri has quit IRC | 21:32 | |
*** emagana has joined #openstack-meeting-3 | 21:33 | |
*** chuckC has quit IRC | 21:33 | |
*** emagana has quit IRC | 21:33 | |
*** emagana has joined #openstack-meeting-3 | 21:34 | |
*** devlaps has joined #openstack-meeting-3 | 21:35 | |
*** rand738 has quit IRC | 21:40 | |
*** rand738 has joined #openstack-meeting-3 | 21:40 | |
*** otherwiseguy has quit IRC | 21:41 | |
*** shakamunyi has joined #openstack-meeting-3 | 21:41 | |
*** otherwiseguy has joined #openstack-meeting-3 | 21:43 | |
*** emagana has quit IRC | 21:49 | |
*** emagana has joined #openstack-meeting-3 | 21:52 | |
*** chuckC has joined #openstack-meeting-3 | 22:02 | |
*** ttrifonov is now known as ttrifonov_zZzz | 22:07 | |
*** chuckC has quit IRC | 22:07 | |
*** otherwiseguy has quit IRC | 22:25 | |
*** otherwiseguy has joined #openstack-meeting-3 | 22:35 | |
*** s3wong has left #openstack-meeting-3 | 22:45 | |
*** shakamunyi has quit IRC | 22:51 | |
*** boris-42 has quit IRC | 22:57 | |
*** boris-42 has joined #openstack-meeting-3 | 22:58 | |
*** david-lyle has quit IRC | 22:59 | |
*** gduan has quit IRC | 23:00 | |
*** garyduan has joined #openstack-meeting-3 | 23:01 | |
*** chuckC has joined #openstack-meeting-3 | 23:01 | |
*** banix has quit IRC | 23:02 | |
*** david-ly_ has joined #openstack-meeting-3 | 23:03 | |
*** mwagner_ has joined #openstack-meeting-3 | 23:03 | |
*** emagana has quit IRC | 23:04 | |
*** overlayer has joined #openstack-meeting-3 | 23:12 | |
*** overlayer has quit IRC | 23:14 | |
*** otherwiseguy has quit IRC | 23:24 | |
*** beyounn has quit IRC | 23:42 | |
*** beyounn has joined #openstack-meeting-3 | 23:43 | |
*** beyounn has quit IRC | 23:54 | |
*** david-ly_ has quit IRC | 23:55 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!