18:04:03 <SumitNaiksatam> #startmeeting networking_policy
18:04:04 <openstack> Meeting started Thu Feb 18 18:04:03 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:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:04:06 <songole> hemanth uploaded a new patch for BP
18:04:09 <openstack> The meeting name has been set to 'networking_policy'
18:04:23 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#Feb_18th.2C_11th.2C_4th.2C_2016
18:04:38 <SumitNaiksatam> #topic Bugs
18:05:12 <SumitNaiksatam> I am being told that there is one bug which is shaping up as critical: #link https://bugs.launchpad.net/group-based-policy/+bug/1407325
18:05:12 <openstack> Launchpad bug 1407325 in Group Based Policy "policy-classifier CLI/GUI does not option for protocol number" [Low,Confirmed] - Assigned to Sumit Naiksatam (snaiksat)
18:05:17 <SumitNaiksatam> need to investigate more
18:05:29 <SumitNaiksatam> songole: hemanth referred to the above one
18:06:01 <SumitNaiksatam> hemanthravi: ah, right timing
18:06:18 <hemanthravi> hi
18:06:48 <SumitNaiksatam> regarding the issue you mentioned offline
18:07:28 <hemanthravi> referring to the protocol field issue?
18:07:45 <SumitNaiksatam> yeah
18:08:03 <SumitNaiksatam> so you have to be able to pass in a protocol number?
18:08:12 <hemanthravi> https://bugs.launchpad.net/group-based-policy/+bug/1407325
18:08:12 <openstack> Launchpad bug 1407325 in Group Based Policy "policy-classifier CLI/GUI does not option for protocol number" [Low,Confirmed] - Assigned to Sumit Naiksatam (snaiksat)
18:08:35 <hemanthravi> currently we don't allow values other than icmp/tcp/udp/* for proto field.
18:08:35 <SumitNaiksatam> that bug has been created in GBP but talks about the CLI not having support
18:08:43 <ivar-lazzaro> hi
18:08:45 <SumitNaiksatam> at any rate the API supports a protocol number: #link https://github.com/openstack/group-based-policy/blob/master/gbpservice/neutron/extensions/group_policy.py#L218-L235
18:08:49 <SumitNaiksatam> ivar-lazzaro: hi
18:08:52 * tbachman waves to ivar-lazzaro
18:09:09 <hemanthravi> it doens't allow for a specific protocol no for eg: 50 to be specified
18:09:37 <SumitNaiksatam> hemanthravi: API allows a protocol number between 0 and 255
18:10:22 <hemanthravi> not sure if the bug is only in CLI, but apparently neither GUI nor CLI allow for other values
18:10:38 <SumitNaiksatam> hemanthravi: and the CLI should also allow it: #link https://github.com/openstack/python-group-based-policy-client/blob/master/gbpclient/gbp/v2_0/groupbasedpolicy.py#L686-L690
18:12:00 <SumitNaiksatam> hemanthravi: we also test the CLI with protocol number 50: #link https://github.com/openstack/python-group-based-policy-client/blob/master/gbpclient/tests/unit/test_cli20_policyclassifier.py#L40-L68
18:12:07 <hemanthravi> will check why the CLI cmd is failing
18:12:55 <SumitNaiksatam> hemanthravi: and I see that I had fixed a bug specifically for this purpose: #link https://github.com/openstack/python-group-based-policy-client/commit/ab1adfc70d9ed302b8b9e507ecbf32740e3d4f91
18:13:46 <SumitNaiksatam> hemanthravi: #link https://bugs.launchpad.net/group-based-policy/+bug/1499916
18:13:46 <openstack> Launchpad bug 1499916 in Group Based Policy UI "GBP classifier create API does not support custom IP protocol numbers" [High,Fix released] - Assigned to ank (ank.b)
18:14:01 <SumitNaiksatam> hemanthravi: it seems we fixed this in the UI as well
18:14:54 <hemanthravi> ok, will check on this. venkat reported he couldn't set a specific value for proto
18:15:12 <SumitNaiksatam> the UI was fixed in late december
18:15:16 <hemanthravi> unless they had to leave it open for a specific reason
18:15:47 <SumitNaiksatam> hemanthravi: the CLI was fixed even prior to that
18:15:57 <SumitNaiksatam> hemanthravi: okay lets sync offline on this
18:16:02 <hemanthravi> prs was to allow traffic for both IPSec and SSL-VPN
18:16:28 <SumitNaiksatam> hemanthravi: ok, which protocol number were you using?
18:17:21 <hemanthravi> 50 or 51
18:17:33 <SumitNaiksatam> ok, should have worked
18:17:47 <hemanthravi> will check on this on my end tonight
18:17:47 <SumitNaiksatam> i see that the server side code was fixed by magesh
18:17:55 <SumitNaiksatam> so venkat can directly talk to him as well
18:18:07 <hemanthravi> ok
18:18:25 <SumitNaiksatam> i dont see any other “critical” issues
18:18:47 <SumitNaiksatam> anyone else have any critical bugs to discuss?
18:19:18 <SumitNaiksatam> ok moving on
18:19:24 <SumitNaiksatam> #topic Mitaka Sync
18:20:00 <SumitNaiksatam> i have posted the server and the client side patches #link https://review.openstack.org/#/q/topic:mitaka-sync
18:20:09 <SumitNaiksatam> this is mostly working now
18:20:17 <tbachman> SumitNaiksatam: congrats!
18:20:24 <SumitNaiksatam> tbachman: oh thanks :-)
18:20:33 * tbachman knows syncing can be painful
18:20:42 <SumitNaiksatam> tbachman: he he he
18:20:44 <tbachman> lol
18:20:54 <SumitNaiksatam> on the server side, i have trouble with the setup of on test module
18:21:04 <SumitNaiksatam> and thats the one that is failing
18:21:29 <SumitNaiksatam> on the client side there is one redundant UT that is failing
18:21:36 <SumitNaiksatam> i will probably reomove
18:21:58 <SumitNaiksatam> i will ping the team once we are all green on these two patches
18:22:46 <SumitNaiksatam> the remaining work would be to sync up the UI and Heat branches, and also create a new devstack for all of this (the gate is already running an updated devstack)
18:23:08 <SumitNaiksatam> please take a look at the patches (especially the server side) if you have time
18:23:37 <ivar-lazzaro> SumitNaiksatam: will do
18:23:41 <SumitNaiksatam> i have also synced up “hacking” with what the rest of OpenStack is using
18:23:44 <SumitNaiksatam> ivar-lazzaro: thanks
18:24:06 <SumitNaiksatam> unfortunately that meant a ton of mechanical changes which kind of distracts from the other changes that went in
18:24:22 <SumitNaiksatam> so you will have to sift through a little bit
18:24:51 <SumitNaiksatam> #topic Design Specs
18:25:11 <SumitNaiksatam> NFP #link https://review.openstack.org/#/c/239743
18:25:41 <SumitNaiksatam> hemanthravi: thanks for uploading new patchset, i had a few comments on that
18:25:58 <SumitNaiksatam> ivar-lazzaro: did you get a chance to take a look?
18:25:59 <hemanthravi> SumitNaiksatam, i'll go through the comments and address them
18:26:37 <SumitNaiksatam> hemanthravi: did you get a chance to catch on those comments/questions? if so we can discuss the main issues here?
18:27:02 <hemanthravi> SumitNaiksatam, i haven't gone through your comments yet
18:27:15 <SumitNaiksatam> hemanthravi: okay
18:27:51 <SumitNaiksatam> maybe i pull up a couple of the main issues
18:28:28 <SumitNaiksatam> hemanthravi: i am seeing that in a lot of places you have attribute-specific API/notifications
18:28:49 <SumitNaiksatam> by that i mean, create_xxx_config
18:29:13 <SumitNaiksatam> get_xxx_sharing_info
18:29:18 <SumitNaiksatam> to give a few examples
18:29:51 <SumitNaiksatam> why cant these attributes be set/get on the CRUD for the main resource itself?
18:29:52 <ivar-lazzaro> SumitNaiksatam: sorry d/c. I'll give a look at that spec by this week
18:29:52 <hemanthravi> create_xxx_config should be rolled into either create_network_function_config or
18:29:57 <SumitNaiksatam> ivar-lazzaro: np
18:29:59 <hemanthravi> create_network_function_device_config
18:30:22 <SumitNaiksatam> hemanthravi: my question is why dont we just have “create_network_function”?
18:30:44 <SumitNaiksatam> or “create_network_function_device”
18:30:56 <SumitNaiksatam> config is a property of those resources
18:31:28 <SumitNaiksatam> we seem to be proliferating the API for individual propertiese
18:31:31 <hemanthravi> was using config to be specific in apis to the configurator. didn't want to confuse that with
18:32:26 <hemanthravi> create_network_function which will include both creating the instance as well as configuring it
18:32:52 <hemanthravi> i'll take a look again and address them
18:32:57 <SumitNaiksatam> hemanthravi: i think the API semantics are in the context of the component that supports it, so i am guessing there would not be any confusion
18:32:59 <SumitNaiksatam> hemanthravi: thanks
18:33:20 <SumitNaiksatam> hemanthravi: also i noticed in places that the API was not symmetric
18:33:37 <SumitNaiksatam> hemanthravi: you had a create, but not update and delete, and in other places you just had a get
18:33:50 <SumitNaiksatam> so that was one thing that felt strange
18:34:01 <hemanthravi> i might have missed the update/delete. will add them
18:34:13 <SumitNaiksatam> hemanthravi: ok, thanks
18:34:22 <SumitNaiksatam> hemanthravi: also regarding the configuration VM
18:34:33 <SumitNaiksatam> configuration -> configurator
18:35:03 <SumitNaiksatam> hemanthravi: it would be good to provide more details on how this is going to be managed
18:35:27 <SumitNaiksatam> who creates it, what is the workflow, etc
18:35:46 <hemanthravi> ok will add that
18:35:53 <SumitNaiksatam> hemanthravi: thanks
18:36:34 <SumitNaiksatam> hemanthravi: has magesh read this latest revision of the spec?
18:36:57 <hemanthravi> yes, working on it together with magesh
18:37:28 <SumitNaiksatam> okay, since he is implementing some of this, would hope that he is on the same page with the discussion we are having
18:37:48 <hemanthravi> will also go through the comments with magesh
18:37:55 <SumitNaiksatam> hemanthravi: thanks
18:38:06 <hemanthravi> and sync up with on the work-flow for the configurator vm
18:38:23 <SumitNaiksatam> perhaps good for songole to review the latest patchset as well ;-)
18:38:28 <hemanthravi> sync up with magesh
18:38:45 <SumitNaiksatam> any other questions for hemanthravi today?
18:38:53 <songole> SumitNaiksatam: just joined back. which one are you referring to?
18:39:00 <SumitNaiksatam> songole: NFP spec
18:39:15 <songole> SumitNaiksatam: ah
18:39:35 <hemanthravi> songole, can you review the spec today/tom
18:39:46 <songole> ok.
18:39:53 <SumitNaiksatam> songole: i know you have been in the discussion, but just want to make sure that what we have documented is what we actually have in mind
18:40:32 <songole> got it
18:40:48 <SumitNaiksatam> ivar-lazzaro: hemanthravi songole: also as for documentation, i would like to propose that going forward implementation patches should be accompanied by devref patch
18:41:23 <SumitNaiksatam> if the spec is in good shape, we can just copy content from that
18:42:09 <SumitNaiksatam> but it will help to have the devref be simultaneously updated with teh impl patch
18:42:20 <SumitNaiksatam> else we dont have consistent design documentation
18:42:33 <SumitNaiksatam> i will create the structure for devref in tree
18:42:54 <SumitNaiksatam> ivar-lazzaro: hemanthravi songole: do you agree?
18:43:25 <songole> SumitNaiksatam: +1
18:43:32 <SumitNaiksatam> songole: ok
18:43:33 <ivar-lazzaro> SumitNaiksatam: for big features, I agree... I wonder if we should do the same for vendor specific driver improvements
18:43:49 <SumitNaiksatam> ivar-lazzaro: not so sure about vendor specific driver improvements
18:43:54 <ivar-lazzaro> SumitNaiksatam: not even sure we should require a spec for that
18:44:21 <SumitNaiksatam> ivar-lazzaro: i dont think we should mandate that for vendor specific patches
18:44:26 <SumitNaiksatam> ivar-lazzaro: yes for the spec either
18:44:43 <SumitNaiksatam> although it would be nice to have
18:44:55 <ivar-lazzaro> SumitNaiksatam: so in that case the process would be to open a BP without a spec? Or a bug in whishlist?
18:45:12 <hemanthravi> SumitNaiksatam, what needs to be done when posting the imp patch(es)
18:45:32 <ivar-lazzaro> For big changes I agree, but sometimes there are just small improvements (that get hidden behind bug IDs which is not ideal :p)
18:45:37 <SumitNaiksatam> ivar-lazzaro: i would imagine that even an enhancement bug should be fine for tracking purposes
18:45:50 <ivar-lazzaro> SumitNaiksatam: ok, thanks for clarifying
18:46:01 <ivar-lazzaro> +1 on the devref for upstream changes though
18:46:10 <SumitNaiksatam> ivar-lazzaro: okay
18:46:12 <SumitNaiksatam> hemanthravi: i think i mispoke and that might have caused confusion
18:46:23 <SumitNaiksatam> so devref is not a separate patch
18:46:33 <SumitNaiksatam> its a rst file that you would include with your impl patch
18:46:46 <SumitNaiksatam> and would capture the design of what you are implementing in that patch
18:47:13 <hemanthravi> got it, does the impl patch refer to the rst in the comment?
18:47:14 <SumitNaiksatam> if you are fixing a bug, and that fix changes an existing design, then you update an existing devref
18:47:26 <SumitNaiksatam> hemanthravi: the rst will be in tree
18:47:34 <hemanthravi> ok
18:47:44 <SumitNaiksatam> hemanthravi: so we will have a place for that (which i need to create)
18:48:07 <SumitNaiksatam> hemanthravi: the spec in gerrit will be for discussions prior to the implementation
18:48:37 <SumitNaiksatam> hemanthravi: at the point the spec is approved, and the implementation starts, the devref will serve as reference doc for the design
18:49:07 <SumitNaiksatam> hemanthravi: in most cases, i would imagine that you would use the contents of the spec initially to start populating the devref
18:49:26 <hemanthravi> ok
18:49:34 <SumitNaiksatam> assuming the implementation design doesnt diverge too much from the approved spec :-)
18:50:09 <SumitNaiksatam> over time, and as a team effort, we should retroactively add devref for existing features as well
18:50:27 <SumitNaiksatam> #topic Open Discussion
18:50:44 <SumitNaiksatam> tbachman: i am guessing you are waiting to say something :-P
18:50:47 <tbachman> lol
18:50:49 <tbachman> which part?
18:50:50 <tbachman> patch?
18:51:03 <SumitNaiksatam> tbachman: just kidding, but yeah that too
18:51:15 * tbachman is a lurker
18:51:15 <tbachman> lol
18:51:22 <SumitNaiksatam> tbachman: anything you wanted to discuss on that?
18:51:34 <SumitNaiksatam> ivar-lazzaro: you think tbachman’s patch is in good shape now?
18:51:34 <tbachman> Just wanted folks to have a look if they have the cycles
18:51:35 <tbachman> https://review.openstack.org/#/c/280475/
18:52:01 <tbachman> I added a bug for it (as per ivar-lazzaro’s suggestion)
18:52:29 <SumitNaiksatam> tbachman: yes thanks, it helps with tracking
18:52:31 <tbachman> and I think I addressed his concerns with the latest patch set
18:52:35 <tbachman> SumitNaiksatam: np!
18:52:37 <ivar-lazzaro> SumitNaiksatam: need to look at it after the changes
18:52:40 <SumitNaiksatam> tbachman: okay will take a look
18:52:41 * tbachman is still learning the ropes
18:52:44 <tbachman> SumitNaiksatam: thx!
18:52:46 <SumitNaiksatam> ivar-lazzaro: sure, np
18:52:47 <ivar-lazzaro> will never get used to the new gerrit GUI
18:52:55 <tbachman> ivar-lazzaro: lol
18:52:56 <SumitNaiksatam> ivar-lazzaro: :-)
18:54:27 <SumitNaiksatam> anything else for today?
18:55:04 <SumitNaiksatam> alright thanks everyone for joining!
18:55:13 <SumitNaiksatam> bye!
18:55:19 <songole> bye
18:55:19 <tbachman> SumitNaiksatam: l8r!
18:55:22 <hemanthravi> bye
18:55:26 <SumitNaiksatam> #endmeeting