18:00:53 #startmeeting networking_policy 18:00:54 Meeting started Thu Jul 3 18:00:53 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:55 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:57 The meeting name has been set to 'networking_policy' 18:01:05 #info agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy 18:01:18 #info Juno specification submission deadline: July 10th, specification approval deadline: july 17th 18:01:57 SumitNaiksatam: hi 18:02:04 we need to revisit and check if we need to submit any more blueprints for the stuff we haven’t addressed yet (outside of what is in the group policy umbrella blueprint) 18:02:12 hello 18:02:13 banix: hi again :-) 18:02:29 Seems like meeting has started... 18:02:45 s3wong: yeah welcome, just started, you were called out earlier :-P 18:02:52 s3wong: AIs assigned! 18:03:14 #topic Resource Model/API/DB/Plugin Update 18:03:42 So all patches have been posted now (later patches need a rebase) 18:04:19 and have been using a patch name convention: GP-API/DB/PLG/1/2/3 18:04:24 SumitNaiksatam: Is any update expected to these at this point? 18:04:35 * GP-API/DB/PLG-1/2/3 18:05:05 rkukura: i dont think there are any outstanding comments for GP-API/DB/PLG-1 18:05:27 rkukura: well apart from the one you had for driver UTs, 18:05:40 and i have not put the DB migration script yet 18:05:56 but i dont think i will be doing these today 18:06:11 SumitNaiksatam: I think Paul Michali put a -1 on the latest gp-api-1 regarding copy.copy() 18:06:21 rkukura: ah i didnt see that 18:06:45 copy.copy() was used per markmcclain’s comments 18:06:55 SumitNaiksatam: It would be good to know if this will force a quick update, or is not really an issue 18:06:58 i will take a look as to what pcm’s comment is 18:07:11 SumitNaiksatam: Thanks 18:07:54 rkukura: i dont understand the comment as much 18:08:09 rkukura: using copy() versus copy.copy() or copy.deepcopy() 18:08:34 deepcopy() is required wherever there are nested args, so i am not sure why a shallow copy would be used there 18:08:45 I think he is concerned that copy.copy() copies the dictionary, but does not copy the items in it 18:08:56 i dont know the difference between copy() versus copy.copy() 18:09:17 I think copy.copy() is fine if its a dict of string->string mappings 18:09:25 rkukura: copy.copy() does a shallow copy, right? 18:09:28 rkukura: yeah 18:09:47 But if its a dict of dicts, then copy.deepcopy() may be needed if the nested dicts should be copied. 18:09:51 rkukura: so currently copy.copy() and copy.deepcopy() is used selectively whereever appropriate 18:10:09 at least that was the intention 18:10:49 ok i will go back and check 18:10:52 His comment is about a dict of dicts 18:11:07 rkukura: so that needs a deepcopy(), and i believe thats what i have 18:11:24 line 79 is a copy.copy() 18:11:38 I’m not sure its really a problem. 18:11:50 rkukura: okay i will check after the meeting 18:11:57 Thanks 18:12:01 rkukura: expect another rev in that case 18:12:30 per reviewer’s comment there is a change in base URI: /gp --> /grouppolicy 18:12:37 any objections? 18:12:45 its more typing if you are doing this manually 18:13:05 and the convention in neutron earlier was to use acronyms like lbaas, fwaas, etc 18:13:20 but i went with the suggestion to spell it ouy 18:13:23 *out 18:13:36 attribute name change: default_subnet_prefix_length --> subnet_prefix_length 18:13:50 SumitNaiksatam: Thanks! 18:14:00 hopefully there are not more name changes 18:14:17 so we did a quick rev on the group policy spec to reflect all the name changes 18:14:24 actually mestery did that (thanks!) 18:14:26 SumitNaiksatam: grouppolicy is good 18:14:28 I really did not want a config variable in the implicit_policy driver called default_default_subnet_prefix_length! 18:14:45 however the above attribute name change is not reflected in that 18:14:48 rkukura: ok 18:14:51 banix: ok 18:15:14 SumitNaiksatam: how about CLI commands? Use gp_ or grouppolicy_ ? 18:15:16 so in general (off-topic), has anyone pulled the neutron-spec repo recently? 18:15:32 songole: thanks for bringing that up, lets take that up in CLI update 18:15:39 I don’t care about gp_ vs. grouppolicy_, but we need to nail it down ASAP 18:15:52 SumitNaiksatam: ok 18:16:05 SumitNaiksatam: I have - anything wrong? 18:16:13 I meant in the URIs 18:16:19 s3wong: i dont seee the latest merges 18:16:27 rkukura: songole’s question was not on the URI 18:16:45 s3wong: the latest commit i saw in that repo was june 25th 18:16:46 realized that 18:17:02 #link https://github.com/openstack/neutron-specs 18:17:19 but a bunch of patches have been “merged” since 18:17:37 so i wanted to put one more rev for the GP-spec, but i couldnt make progree 18:17:41 SumitNaiksatam: hmm... OK, I saw the files, didn't check the date 18:17:49 anyone have any idea? 18:17:54 s3wong: see the latest commit 18:18:32 SumitNaiksatam: 8 days ago... 18:18:36 s3wong: yeah 18:18:39 and thats not right 18:19:04 so i dont know, perhaps a question for the infra team, i did not get a chance to follow up 18:19:29 anyone, whenever this gets sorted please expect another minor rev, with the attribute name change 18:20:13 anything anyone else wanted to edit in the spec (any inconsistency?) please let me know, or if you want to post the update please go ahead, and include the update to the subnet_prefix_length attribute (coordinate with me) 18:20:34 rkukura had comments on adding explicit UT on the plugin patch 18:20:50 the code path for the dummy driver currently gets exercised 18:20:59 with the existing UTs 18:21:13 but it will be good to have specific UTs and will help with the downstream patches 18:21:18 yes, that patch didn’t verify that the right driver methods get called with context objects containing the right data 18:21:20 So banix is working on adding driver-specific UTs to GPM-PLG-1 18:21:39 SumitNaiksatam, banix: great! 18:21:46 * banix wakes up 18:21:53 banix: :D 18:22:14 sorry guys :) just kidding. I have been following 18:22:30 i have also not put the DB migration script in GP-DB-1 18:22:58 whats the thinking, should we add it upfront, or should we add one script at the end of the series? 18:24:04 ok, let me know if you have thoughts 18:24:15 #topic Mapping Model/Driver Update 18:24:18 rkukura: over to you 18:24:18 Does not having the migration actually prevent deploying neutron-server with the plugin? 18:24:37 rkukura: perhaps, so its required upfront 18:24:43 will add it 18:25:11 and we can modify the same script in the subsequent patches 18:25:12 I was on PTO most of the past week, but managed to make some progress, especially while stuck at JFK most of yesterday 18:25:39 * SumitNaiksatam notes that JFK is productive office location 18:25:41 The implicit_driver patch is done, but it and the other gpm-* patches need to be rebased 18:25:56 Free wi-fi in the wine bar next to our gate helped 18:26:33 * SumitNaiksatam notes that wine bar is an important detail 18:26:53 kept my wife from being too annoyed that I was working 18:26:54 rkukura: great, good to hear about the implicit-driver 18:27:04 big storm came through the city 18:27:07 yesterday 18:27:20 So I will rebase gpm-ipd and the other gpm-* patches and post today 18:27:27 rkukura: ok great 18:27:43 rkukura: the mapping dirver, how is that coming along? 18:27:46 I’m now going to get the gpm-rmd (resource_mapping driver) into a functional state and post ASAP 18:28:24 rkukura: great, i guess we need that in ASAP to get past the current -2 on the first patch 18:28:24 rkukura: which repo has you been working off of? I couldn't find it on noironetworks/neutron-group-policy 18:28:24 Hopefully this will all some if the Sumit’s initial patches to start merging, even if this one is still WIP 18:28:46 rkukura: yes, i agree, i think its a reasonable expectation 18:28:47 s3wong: I’m working off gerrit 18:28:59 hi 18:29:05 rkukura: I see 18:29:09 sorry oops wrong window 18:29:39 rkukura: any blockers, or anything you wanted to bring up for discussion? 18:29:52 I should be able to make some progress on gpm-rmd over the long weekend (since I’ve just had a nice vacation) and hopefully have it pretty much complete by Monday. 18:30:03 rkukura: ok 18:30:04 rkukura: OK - I will need to look at your mapping driver part to think about the contract rendering part 18:30:19 No blockers right now, just need to know whether to rebase on the current gp-* patches or wait for updates 18:30:55 rkukura: ok, i have to run to another meeting immediately after this, but will get to it later in the day after that 18:30:59 rkukura: SumitNaiksatam: in the mean time, I will look at SumitNaiksatam 's latest contract API/DB patches to see which fields need to get into mapping DB 18:31:01 s3wong: Hopefully a WIP patch, probably missing UTs, will help with that 18:31:02 rkukura: i will update once i am done 18:31:13 rkukura: I am sure it will :-) 18:31:23 s3wong: thanks, we have a separate agenda item for you :-) 18:31:33 rkukura: thanks for the update 18:31:47 #topic CLI/Client update 18:31:55 songole: over to you 18:32:05 API-1 patch is posted 18:32:16 https://review.openstack.org/#/c/104013/ 18:32:33 songole: sweet, thanks so much for jumping on it in hemanth’s absence and getting it ready in quick time 18:32:34 I will update the name changes 18:32:40 songole: thanks 18:32:56 So, should it be gp_ or grouppolicy_? 18:33:01 songole: so you had a question on whether CLI should start with gp- or grouppolicy- 18:33:06 songole: yeah 18:33:23 i think the current practice in neutron is to spell it out? 18:33:29 i think grouppolicy_ would be better at the end of the day with auto completion etc 18:33:50 Are acronyms used for the other services? 18:34:01 i dont have a devstack ready here to check quickly 18:34:15 rkukura: i think we are probably using a mixed approach 18:34:30 s3wong: do we go loadbalancer- or lb- in the lbaas CLI? 18:34:36 I like acronyms ;) 18:34:44 i know for fwaas we have “fw-“ 18:34:48 vpn, lb 18:34:53 rkukura: yes, we all kknow that :-) 18:34:55 neutron router-interface-add …. 18:35:08 SumitNaiksatam: I think it is 'loadbalancer' 18:35:15 yeah, i think we have been using a mixed approach 18:35:17 SumitNaiksatam: it is lb_ 18:35:32 songole: seems like I got it wrong :-) 18:35:33 floatingip is expanded 18:35:33 I like acronyms, but I don’t like “shortenned” words 18:35:43 there is probably a character threshold beyond which we resort to acronyms 18:36:12 to banix’s earlier point, CLI is auto completed 18:36:28 so we really dont need to type even if we have the long form 18:36:48 (my personal perference is also with the acronym) 18:37:00 but perhaps we can roll with “grouppolicy_”? 18:37:23 the two ‘p’s in between make it tricky if you chose not to autocomplete 18:37:58 SumitNaiksatam: agree 18:38:15 SumitNaiksatam: so what was the reviewer's reason to move from 'gp' to 'grouppolicy'? 18:38:23 that 'gp' can mean something else? 18:38:48 s3wong: i dont know 18:38:53 * regXboi wanders in late with a classifier question for the open discussion 18:39:04 regXboi: sure we will have time for that 18:39:13 SumitNaiksatam: thx 18:39:24 s3wong: i chose not to deliberate too much on subjective issues 18:39:38 SumitNaiksatam: fair enough :-) 18:39:46 SumitNaiksatam: so, the consensus is grouppolicy_? 18:40:13 any objections? 18:40:18 My vote would be gp_, but won’t object 18:40:25 no objections 18:40:38 i will take that as a no objection from rkukura 18:40:41 doesn't matter, really :-) do have to settle on one 18:40:46 I'd agree with rkukura, as it is shorter to type, but I won't object either 18:40:55 regXboi: you dont need to type 18:41:00 regXboi: its auto completed 18:41:30 regXboi: however we the base URI is /grouppolicy, in case if some level of consistency needs to exist between them 18:41:45 dont hear any objections yet 18:41:47 consistency is always good 18:41:55 ok, done then! 18:42:21 #agreed CLI prefix is grouppolicy_ (not gp_) 18:42:28 ok 18:42:35 songole: any other blockers for you? 18:42:50 no. I am unblocked! 18:43:14 songole: nice, and thanks again for stepping up on this! 18:43:31 we are running a bit slow today 18:43:42 #topic Security Group mapping update 18:43:47 s3wong: over to you 18:43:55 progress? 18:44:03 i know you ahve dependency 18:44:13 but still… ;-P 18:44:14 So as we talked about last week, it seems like the only item that needs to be added to mapping DB would be the security group ID 18:44:42 s3wong: do we have a document? or perhaps edit to the existing mapping google doc, to capture your thoughts? 18:45:17 SumitNaiksatam: yes, documentation is the first step - where is the existing mapping doc? 18:45:37 s3wong: Any thoughts on whether to incrementally modify the SGs as various policies change, or just trigger regenerating them? 18:45:47 s3wong: its linked somewhere from the wiki :-P 18:45:53 SumitNaiksatam: OK 18:46:14 #link https://docs.google.com/a/noironetworks.com/document/d/134P7TJdiIfjPWbmstSTY4vp9E6oRYTFs64ON3thFxhI/edit?usp=sharing 18:46:21 s3wong: ^^^ 18:46:44 s3wong: sorry for being pushy, but when can we expect an update? 18:46:47 rkukura: I am thinking at this point we have one security group for the whole contract, and have each policy-rule be added as incremental update 18:47:05 rkukura: do you see any potential problem? 18:47:05 s3wong: ok 18:47:30 SumitNaiksatam: yes, after the Service Insertion spec update, I will update the doc to reflect on my thoughts 18:47:33 s3wong: ok 18:47:35 s3wong: I was thinking we’d need a SG per EPG or something like that 18:48:21 rkukura: OK - but if an EPG consumes or provides more than one contracts, do we simply consolidate? 18:48:32 s3wong: thanks! 18:48:49 rkukura: (and this also makes future expansion on stuff like label difficult to manage, right?) 18:49:01 s3wong: I was thinking that we’d need to merge the rules from all contacts into one SG. I don’t think a port can use more than one SG. 18:49:13 s/contacts/contracts/ 18:49:25 rkukura: i dont think so either 18:49:30 rkukura: Oh, OK. That makes sense - have to work with limitation on SG 18:49:53 yup one sg 18:49:55 If an EPG has multiple subnets, I think they could all use the same SG, but I’m not sure 18:50:13 #action sync up between s3wong rkukura mandeep SumitNaiksatam on SG mapping, s3wong to put some initial thoughts in https://docs.google.com/a/noironetworks.com/document/d/134P7TJdiIfjPWbmstSTY4vp9E6oRYTFs64ON3thFxhI/edit?usp=sharing 18:50:31 SumitNaiksatam: will update the doc over the Indpendence Day weekend 18:50:44 s3wong: thanks! 18:50:55 * SumitNaiksatam realizes he is not making too many friends here! 18:51:23 s3wong: so on the code front you have a dependency, and are blocked 18:51:24 SumitNaiksatam: well, if rkukura works during his PTO, it is only appropriate that I also work during ID4 :-) 18:51:54 SumitNaiksatam: yes, for one, action isn't defined yet from your contract patch 18:52:24 s3wong: I intended to get a lot more work done than I actually did, so please don’t feel any obligation 18:52:30 SumitNaiksatam: and (2) I would like to see rkukura 's mapping driver patch once it is available 18:52:46 s3wong: ok, makes sense 18:53:06 s3wong: i think as long as we have a plan in place, please shout out to us if you are blocked 18:53:15 rkukura: cool :-) 18:53:22 SumitNaiksatam: certainly 18:53:37 we have our backs to the wall in terms of J2 deadline 18:53:44 SumitNaiksatam: I was stuck in an event over the last two days, so progress has been slow... sorry about that 18:53:57 um... quick acro expansion: SG = ?? 18:54:00 s3wong: np at all 18:54:07 regXboi: security group 18:54:09 regXboi: security group 18:54:10 regXboi: Security Group 18:54:11 ah thanks 18:54:19 s3wong: thanks much for the update 18:54:28 I was suddenly thinking service g.... and getting confused :) 18:54:53 #topic services’s integration 18:54:58 banix: any thoughts? 18:55:01 or update 18:55:05 damn, me again :-) ? 18:55:12 to s3wong 18:55:16 s3wong: i tried to be subtle 18:55:30 s3wong: you can blame banix now! :-P 18:55:41 So last week I met with mandeep and SumitNaiksatam , and decided to not wait for ServiceBase for 'redirect' 18:56:20 s3wong: ok good, i believe there is a bit of dependency there as well on the driver patches that are expected 18:56:26 s3wong: thanks for that update 18:56:32 #topic open discussion 18:56:38 regXboi: go for it 18:56:38 may I? 18:56:49 so I was reviewing the GBP patch sets 18:56:56 regXboi: yes thanks 18:57:03 and I'm missing a policy classifier that goes beyond the protocol 18:57:19 specifically I have a use case where I want to look at the first octet of the MAC 18:57:27 because of different policies for multicast traffic 18:57:59 regXboi: By design the classifiers are L4+ and the endpoints (L3 and below) are expected to be identified by group membership 18:58:08 doesn't matter 18:58:18 regXboi: We need to think of multicast specifically 18:58:38 I'm saying that an L4+ classifier appears to miss the boat 18:58:45 regXboi: i believe our current classifier definition is extensible 18:59:02 regXboi: I get your point on multicast, and I agree that it is an problem 18:59:04 SumitNaiksatam: I hope so, because I'm going to put comments in looking to do that 18:59:18 so be prepared to see some comments on the classifiers for that 18:59:21 regXboi: sure, and duly noted 18:59:28 otherwise the patch sets will be getting +1s from me down the line 18:59:43 (for what it is worth) 18:59:57 SumitNaiksatam: that was all I had 18:59:57 regXboi: definitely helps a lot to get the +1 19:00:21 * regXboi stole the first X minutes of this meeting to actually *DO* the reading :) 19:00:26 regXboi: as long as there is a path to evolve, i think we should keep rolling 19:00:46 regXboi: otherwise we are not going to get this update off the ground 19:00:50 regXboi: I agree that the multicast use case needs to be resolved (as opposed to that we need to extend the classifier to L3 and below ;-) 19:01:01 SumitNaiksatam: I'm good with that - I'll probably leave the ones with comments at 0 for the nonce 19:01:06 so I'm not blocking 19:01:17 regXboi: sure 19:01:24 mandeep: I'd prefer not to have different mechanisms 19:01:31 mandeep: yes, hopefully you don't go back to discussing adding IP addresses and what not in classifier 19:01:42 * regXboi cringes 19:01:46 s3wong: That was the point that I was making 19:01:51 ok we are runnning a couple of mins over 19:02:06 who will be in MN next week? 19:02:13 we can talk about this then... 19:02:28 i cant make it 19:02:36 i think apart from me and you rkukura 19:02:37 :( 19:02:39 I will not be there either 19:02:40 won't be there, unfortunately 19:02:47 ok... so we'll take this to email then 19:03:05 I'll put together some thoughts in comments and we can branch from that 19:03:15 regXboi: sounds good 19:03:27 regXboi: may be a quick call will converge faster 19:03:30 regXboi: sounds good, will follow up specifically on this with you 19:03:37 what mandeep said 19:03:40 mandeep: the trick is finding time :( 19:03:49 ok i will wrap it here 19:03:56 thanks all and happy 4th of July! 19:03:57 banix will tell you: I'm a really popular guy 19:04:00 #endmeeting