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