18:04:20 <SumitNaiksatam> #startmeeting networking_policy 18:04:21 <openstack> Meeting started Thu Feb 25 18:04:20 2016 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:04:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:04:24 <openstack> The meeting name has been set to 'networking_policy' 18:04:32 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#Feb_26th.2C_18th.2C_11th.2C_4th.2C_2016 18:04:40 * tbachman waves to SumitNaiksatam 18:04:45 <ivar-lazzaro> hi 18:04:46 <SumitNaiksatam> no new critical bugs 18:04:52 <SumitNaiksatam> tbachman: ;-) 18:05:13 <SumitNaiksatam> anyone else in the team stumble across any critical bugs? 18:05:38 <SumitNaiksatam> we have one pending fairly high priority one: 18:06:21 <SumitNaiksatam> #link https://bugs.launchpad.net/group-based-policy/+bug/1549561 18:06:21 <openstack> Launchpad bug 1549561 in Group Based Policy "Disallow identical external routes on external segments" [Medium,Confirmed] - Assigned to Amit Bose (bose) 18:06:36 <SumitNaiksatam> amit has a patch: #link https://review.openstack.org/#/c/284496/ 18:06:43 <SumitNaiksatam> rkukura: hi 18:06:48 <rkukura> hi - sorry I’m late 18:07:15 <SumitNaiksatam> since hemanthravi wanted to leave early, lets start with the design spec discussion first 18:07:25 <SumitNaiksatam> #topic Design Specs 18:07:44 <SumitNaiksatam> Network Function Plugin Framework for GBP #link https://review.openstack.org/239743 18:07:53 <SumitNaiksatam> hemanthravi: i dont see update in the spec yet 18:08:17 <hemanthravi> SumitNaiksatam, i'll do it over the next couple of days, need to sync up with the team 18:08:17 <SumitNaiksatam> this implementation patch was posted by ahmed: #link https://review.openstack.org/#/c/282292 18:08:22 <SumitNaiksatam> hemanthravi: ok 18:08:26 <hemanthravi> they are busy getting some patches in 18:08:31 <SumitNaiksatam> regarding the impl patch 18:08:34 <SumitNaiksatam> hemanthravi: sure 18:09:00 <SumitNaiksatam> firstly, we would need a devref document to make it clear as to what in being attemped in the patch 18:09:11 <SumitNaiksatam> (beyond the summary in the commit message) 18:09:13 <hemanthravi> there will be one change in moving the config APIs handling to the process on the Network Function Manger 18:09:23 <hemanthravi> as opposed to the Agent on the network node 18:09:24 <igordcard_> hi all 18:09:28 <SumitNaiksatam> hemanthravi: okay, we can review once you update the spec 18:09:30 <SumitNaiksatam> igordcard_: hi 18:09:35 <hemanthravi> SumitNaiksatam, ok 18:09:50 <SumitNaiksatam> hemanthravi: i think the team would need to know the context for #link https://review.openstack.org/#/c/282292 18:10:14 <SumitNaiksatam> hemanthravi: it will be easier to understand this with the dependent patches 18:10:31 <SumitNaiksatam> hemanthravi: that would tell us how the framework is being used 18:10:59 <hemanthravi> SumitNaiksatam, will adding the devref patch explaing this help 18:11:03 <SumitNaiksatam> hemanthravi: there were also questions about how the applicability of this framework beyond just what you are trying to achieve 18:11:14 <SumitNaiksatam> hemanthravi: yes devref patch will definitely help 18:11:38 <SumitNaiksatam> hemanthravi: but ususally we dont merge a framework component unless there is already a patch which is also using it 18:12:13 <hemanthravi> SumitNaiksatam, ahmed/magesh will be adding those patches... 18:12:20 <SumitNaiksatam> i believe rkukura also had questions on whether what is being attempted is, to any extent, already available in oslo (or, oslo also working on it)? 18:12:23 <hemanthravi> broke it up so that it's easier to review 18:12:53 <SumitNaiksatam> hemanthravi: great, so it would be good to post those patches in whatever state they are in, so that team gets a better context (mark them WIP) 18:13:43 <hemanthravi> i'm not aware of something in oslo that we can use instead 18:13:54 <SumitNaiksatam> hemanthravi: okay 18:14:43 <SumitNaiksatam> hemanthravi: is this framework completely home grown? 18:14:52 <tbachman> Would there be any other libraries that might have something similar? 18:14:57 <SumitNaiksatam> hemanthravi: apart from using multiprocessor 18:15:10 <hemanthravi> multiprocessing is the python framework.. 18:15:14 <tbachman> And are there unique characteristics about this framework that are specific to this project 18:15:26 <SumitNaiksatam> tbachman: kind of what i was wondering as well 18:15:40 <hemanthravi> otherwise it consists of a listener to interface with othe components...and worker processes impl the required funcionality 18:15:49 <hemanthravi> and queues binding them together 18:16:07 <hemanthravi> multiprocessing and queues are from the python multiporcessin 18:16:16 <hemanthravi> g mdoules 18:17:34 <tbachman> Also — if this is needed, does this belong in GBP? In other words, is this a service that many openstack projects would want to leverage? 18:18:40 <hemanthravi> adding this in GBP to provide the rendering backend for the service-chain 18:19:48 * tbachman should spend some time looking at this patch :) 18:19:49 <hemanthravi> we could look at making this independent going forward 18:20:03 <SumitNaiksatam> hemanthravi: okay 18:22:48 <SumitNaiksatam> hemanthravi: in which part of the NFP architecture is this framework being used? 18:23:29 <SumitNaiksatam> hemanthravi: in other words, what does the “listener” and what does the “worker” map to? 18:24:00 <hemanthravi> listener is the interface to listen to RPC from other components in case of network function manger 18:24:30 <hemanthravi> or configuration messages in case of configurator 18:24:39 <hemanthravi> serves an interface to external components 18:24:44 <SumitNaiksatam> hemanthravi: okay, what about the “workers”? 18:24:56 <hemanthravi> and distributes to event-queues which are handled by workers 18:25:24 <hemanthravi> the functionality is being implemented in the context of the workers 18:25:33 <hemanthravi> in effect listener is a distributor 18:25:49 <hemanthravi> workers can scale based on perf requirement 18:26:10 <hemanthravi> number of workers is configurable 18:26:42 <SumitNaiksatam> hemanthravi: okay, but what do these “workers” map to in the diagram shown in the spec 18:26:43 <SumitNaiksatam> ? 18:27:03 <hemanthravi> the same model is used both for the network function manager and the configurator 18:27:15 <SumitNaiksatam> hemanthravi: okay 18:28:17 <hemanthravi> the process model is the same, configurator running in the service tenant talks to the service vms 18:28:42 <SumitNaiksatam> hemanthravi: okay 18:29:32 <hemanthravi> network function manager is responsible for bringing up/down the service vms and the manaing the state changes 18:29:54 <hemanthravi> configurator is stateless and responds to messages from the network function manger 18:30:14 <hemanthravi> providing a path to the service vms to configure and monitor 18:30:45 <hemanthravi> process model is the same for both the modules, the functionality is distinct 18:30:52 <SumitNaiksatam> hemanthravi: okay 18:32:27 <SumitNaiksatam> hemanthravi: you mentioned you had to leave 18:32:59 <SumitNaiksatam> hemanthravi: there are still some more questions, so we can follow up offline later today? 18:33:07 <hemanthravi> yes, will update the spec 18:33:13 <hemanthravi> yes, 18:33:29 <SumitNaiksatam> hemanthravi: okay i will try to reach you in about 30 mins, thanks for the update! 18:33:38 <hemanthravi> ok 18:33:43 <hemanthravi> bye 18:34:03 <SumitNaiksatam> Initial support for Quality of Service #link https://review.openstack.org/#/c/275358/ 18:34:06 <SumitNaiksatam> igordcard_: hi 18:34:11 <igordcard_> SumitNaiksatam: hi 18:34:23 <SumitNaiksatam> i didnt get a chance to follow up since last week 18:35:02 <igordcard_> I have gone back to my PoC work and am working the network service policy possibility 18:35:43 <SumitNaiksatam> igordcard_: okay 18:35:44 <igordcard_> when I have something with NSP I will post that PoC, so we at least have some basic, working, neutron-backed QoS to try 18:35:59 <SumitNaiksatam> igordcard_: okay, great 18:36:12 <SumitNaiksatam> igordcard_: can you document that you are choosing this approach in the spec? 18:36:18 <igordcard_> but if it's completely irrelevant I can focus on some other possibility, like the one QoS action for PRSs 18:36:24 <igordcard_> SumitNaiksatam: okay 18:36:26 <SumitNaiksatam> igordcard_: we can potentially try to close on this particular spec based on that choice 18:38:00 <SumitNaiksatam> igordcard_: if you can do a short update to the spec, i can try to make a soft committment on behalf of the team that we will try to close on this spec by the next meeting? 18:38:59 <igordcard_> SumitNaiksatam: when you mean a close on this spec is it to approve it or? 18:40:05 <SumitNaiksatam> igordcard_: yeah hopefully, or at least give you feedback if a different direction needs to be taken 18:41:04 <igordcard_> SumitNaiksatam: yes I will update the spec describing the route taken for now, as PoC 18:41:17 <SumitNaiksatam> igordcard_: great, thanks 18:41:24 <igordcard_> alright 18:42:00 <SumitNaiksatam> #topic Mitaka sync patches 18:42:38 <NobodyCam> Using username "nobodycam". 18:43:07 <SumitNaiksatam> #link https://review.openstack.org/#/q/topic:mitaka-sync 18:43:33 <SumitNaiksatam> i have posted all the patches 18:43:50 <SumitNaiksatam> i will shortly post a new patchset to address rkukura’s comments 18:44:14 <SumitNaiksatam> i am happy to answer any questions on those patches here 18:45:57 <SumitNaiksatam> ok 18:46:06 <SumitNaiksatam> #topic Open Discussion 18:48:01 <SumitNaiksatam> alright nothing else 18:48:08 <SumitNaiksatam> so lets close for today 18:48:12 <SumitNaiksatam> thanks all for your time! 18:48:18 <SumitNaiksatam> c ya next week, bye! 18:48:19 <tbachman> SumitNaiksatam: thanks for running it! 18:48:20 <rkukura> thanks SumitNaiksatam! 18:48:23 <SumitNaiksatam> #endmeeting