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