18:01:49 <SumitNaiksatam> #startmeeting networking_policy
18:01:50 <openstack> Meeting started Thu Mar 17 18:01:49 2016 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:54 <openstack> The meeting name has been set to 'networking_policy'
18:02:06 <ivar-lazzaro> hi
18:02:10 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#March_17th.2C_10th.2C_2016
18:02:29 <SumitNaiksatam> nothing critical on the bugs reported
18:02:40 <SumitNaiksatam> rkukura: anything to discuss on packaging?
18:02:54 <SumitNaiksatam> rkukura: i expect that we will have new stable releases next week
18:03:14 <rkukura> nothing new - I’ve been trying to get an update from apevec on RDO/Delorean, but no luck
18:03:26 <rkukura> I’ve been looking into the semantic versioning
18:03:38 <SumitNaiksatam> rkukura: ok np, based on that i can switch to the semantic versioning
18:04:09 <SumitNaiksatam> #topic Status attributes
18:04:32 <SumitNaiksatam> so based on the discussion in the last IRC meeting, I updated the patch #link https://review.openstack.org/289530
18:04:33 <rkukura> SumitNaiksatam: agreed we should switch
18:04:41 <SumitNaiksatam> rkukura: okay
18:04:52 <SumitNaiksatam> rkukura: lets discuss when you are here in person
18:05:07 <rkukura> SumitNaiksatam: OK. See http://ttx.re/new-versioning.html for an overview, if you haven’t already.
18:05:17 <SumitNaiksatam> rkukura: thanks, will take a look
18:05:36 <SumitNaiksatam> however, last night i did some more refactoring and broke something fundamental so more than 300 UTs are failing on that patch now
18:05:40 <SumitNaiksatam> i have been trying to fix that
18:06:17 <SumitNaiksatam> i have also not updated the spec to reflect the design changes for collecting the status from the drivers
18:06:26 <SumitNaiksatam> but its there in the implementation patch
18:06:33 <SumitNaiksatam> i will update the spec shortly
18:07:14 <rkukura> SumitNaiksatam: will review both ASAP
18:07:18 <SumitNaiksatam> rkukura: thanks
18:07:59 <SumitNaiksatam> #topic Other Design Specs
18:08:12 <SumitNaiksatam> QoS #link https://review.openstack.org/#/c/275358/
18:08:15 <SumitNaiksatam> igordcard_: hi
18:08:31 <igordcard_> hi
18:08:57 <igordcard_> so the PoC is in progress
18:09:08 <SumitNaiksatam> so I +2’ed the spec
18:09:19 <SumitNaiksatam> can we have one more reviewer push this forward?
18:09:34 <SumitNaiksatam> once its +A’ed i will creaete a new feature branch for this work
18:10:04 <rkukura> SumitNaiksatam: I’ll re-review
18:10:26 <ivar-lazzaro> will be on it too
18:10:32 <SumitNaiksatam> rkukura: thanks, i think at this point the proposal is to experiment in the feature branch and then take it from there
18:10:36 <SumitNaiksatam> ivar-lazzaro: thanks
18:10:50 <SumitNaiksatam> igordcard_: thanks for getting started on the PoC
18:11:06 <SumitNaiksatam> igordcard_: it will be interesting if we have something ready by Austin
18:11:33 <igordcard_> SumitNaiksatam: yes, certainly, it's my hope to
18:11:42 <SumitNaiksatam> igordcard_: thanks
18:12:15 <SumitNaiksatam> NFP framework #link https://review.openstack.org/239743
18:12:44 <SumitNaiksatam> songole: hi
18:12:55 <SumitNaiksatam> i havent been able to take a look at the latest rev from hemanth
18:13:05 <SumitNaiksatam> i think igordcard_ had some comments earlier on terminology
18:13:32 <SumitNaiksatam> but there were some offline discussions on this as well with songole and hemanth, so i am not sure if those have been captured in the latest rev of the spec
18:13:58 <songole> Hi SumitNaiksatam
18:15:01 <SumitNaiksatam> songole: any open issues on the spec that you want to discuss with the team today
18:15:03 <SumitNaiksatam> ?
18:15:11 <songole> I am not sure if they should be part of the spec
18:15:33 * tbachman rushes into the room
18:15:42 <songole> As you suggested, I will keep a design/implementation doc for reference during code review
18:15:42 <SumitNaiksatam> songole: ok, but apart from the new agent you are planning, i think there were a few new things we discussed earlier
18:15:54 <SumitNaiksatam> songole: like the execution of the heat templates
18:16:05 <SumitNaiksatam> tbachman: hi there, we are almost getting done :-P
18:16:10 <tbachman> SumitNaiksatam: sorry!
18:16:19 * tbachman has to set many alarms
18:16:20 <SumitNaiksatam> tbachman: oh no worries, just pulling your leg
18:16:23 <tbachman> lol
18:16:32 <songole> SumitNaiksatam: I have one question regarding south bound APIs
18:16:38 <SumitNaiksatam> songole: yes sure
18:17:09 <songole> Should we put version string in the URI - Prefix? similar to lbaas?
18:17:17 <songole> Like /v1/nfp---?
18:17:40 <SumitNaiksatam> songole: i would propose that this be consistent with the GBP API
18:17:44 <SumitNaiksatam> API version
18:17:50 <SumitNaiksatam> since its all one project
18:18:07 <songole> The alternate design would be to put it in the data..
18:18:21 <SumitNaiksatam> oh sorry, you meant the south bound API
18:18:26 <songole> Yes
18:18:43 <SumitNaiksatam> is this API mainly exercised via RPC?
18:19:07 <songole> This is REST to the southbound as the first step
18:19:13 <SumitNaiksatam> hmmm ok
18:19:14 <songole> to the configurator
18:19:46 <SumitNaiksatam> i guess this can be independent of the NB API version
18:20:16 <SumitNaiksatam> but i am just wondering if all the NB and SB APIs should be consistently versioned to avoid confusion
18:20:19 <songole> orchestrator -> agent -> proxy -> (SB ABP) -> configurator
18:20:24 <SumitNaiksatam> songole: got it
18:20:35 <songole> ABP -> API
18:20:52 <SumitNaiksatam> i do realize that the NB API can evolve independently of the SB API (and vice versa)
18:21:00 <songole> Yes
18:21:12 <SumitNaiksatam> but i would prefer one consistent version to start with (if we had to make a choice)
18:21:20 <SumitNaiksatam> rkukura: ivar-lazzaro igordcard_: what do you guys think?
18:21:48 <SumitNaiksatam> the API songole is referring to is the API called from the new NCP driver to a process which configures the service
18:21:59 <songole> Most openstack APIs have version string prefixed to URIs, I believe
18:22:16 <rkukura> I’m not sure what the OpenStack API WG is recommending on this right now, but I’d follow that.
18:22:18 <SumitNaiksatam> service meaning the network (L4-7) service
18:22:29 <SumitNaiksatam> rkukura: thats a good point
18:22:39 <SumitNaiksatam> songole: i will point you to the WG recommendations
18:22:49 <SumitNaiksatam> though i am not sure they address SB APIs
18:23:34 <SumitNaiksatam> songole: the changes in the design i was referring to were those related to where and how the heat template gets executed
18:24:21 <SumitNaiksatam> songole: that you have the new process, which sends a message back through the proxy channel for the orchestrator to run the heat template
18:24:31 <SumitNaiksatam> songole: also the passing of the tokens back and forth
18:24:42 <SumitNaiksatam> those are relevant to this spec, right?
18:25:30 <SumitNaiksatam> the other thing that came up during the discussion was to augment the definition of our service profile
18:25:56 <SumitNaiksatam> to be able to suggest a form factor for the requested service
18:26:13 <SumitNaiksatam> so a particular service could be run as a VM or a HW appliance or a process
18:26:30 <SumitNaiksatam> so provide an attribute within the service profile to allow indicating this
18:26:50 <songole> SumitNaiksatam: Yes, regarding spec updates
18:27:25 <songole> SumitNaiksatam: should we keep extending the service_profile resource on need basis or
18:27:40 <songole> provide tags similar to flavor framework?
18:27:51 <SumitNaiksatam> songole: open for discussion
18:28:40 <SumitNaiksatam> i think the preference would be to perhaps make this a little more strongly typed
18:29:06 <SumitNaiksatam> meaning having a specific attribute so that the usage and semantics are consistent across deployments
18:29:42 <SumitNaiksatam> in addition we can perhaps explore adding a “meta” field to the service profile
18:29:57 <SumitNaiksatam> for any other vendor specific extensions
18:30:10 <SumitNaiksatam> but the form factor seems a more fundamental property
18:31:54 <SumitNaiksatam> perhaps we can have a more concrete discusison after posting a spec
18:32:31 <SumitNaiksatam> songole: we should add the versioning proposal to the spec as well
18:32:42 <SumitNaiksatam> SB versioning that is
18:32:58 <SumitNaiksatam> songole: thanks for the update
18:33:05 <SumitNaiksatam> #topic Open Discussion
18:33:42 <SumitNaiksatam> regarding the Austin workshop, still planning how to deliver this
18:33:53 <SumitNaiksatam> thats pretty much it from me for today
18:33:59 <SumitNaiksatam> anyone have anything else?
18:34:43 <rkukura> not today
18:34:45 <igordcard_> okay
18:34:53 <SumitNaiksatam> alrighty, thanks all for joining!
18:34:58 <SumitNaiksatam> more next week
18:35:03 <rkukura> thanks SumitNaiksatam!
18:35:10 <SumitNaiksatam> bye!
18:35:11 <songole> thanks
18:35:15 <SumitNaiksatam> #endmeeting