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