18:00:45 #startmeeting networking_policy 18:00:46 Meeting started Thu Jul 31 18:00:45 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:47 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:50 The meeting name has been set to 'networking_policy' 18:01:07 https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#July_31st.2C_2014 18:01:14 #info agenda https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#July_31st.2C_2014 18:01:38 #topic Patches in review 18:01:48 #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches 18:02:17 there is a long standing -2 on the first patch of the series from markmcclain 18:02:54 i have pointed this out in the -dev mailing list 18:03:08 we also requested markmcclain to attend this meeting 18:03:15 however, he does not seem to be online 18:03:35 mestery: How should we proceed on this? 18:03:54 we have one +2 from rkukura on the patch 18:04:05 mandeep: It's hard to proceed unless markmcclain is here, I believe he's on a plane returning from the nova mid-cycle at the moment, but I'm not 100% sure. 18:04:21 mestery: okay 18:04:37 mestery: Quoting salvatore from the mailing list: 18:04:39 I try to avoid -2s as much as possible. I put a -2 only when I reckon your 18:04:39 patch should never be merged because it'll make the software unstable or 18:04:39 tries to solve a problem that does not exist. -2s stick across patches and 18:04:41 mestery: from a project process/policy perspective, is there any remediation to this? 18:04:41 tend to put off other reviewers. 18:05:15 mestery: the issue has been raised in the mailing list as well 18:05:16 mestery: Would you consider this appropriate use of -2 (assuming that definition)? 18:05:29 I don’t think it would hurt to encourage other core reviewers to review the initial patches and place their votes. 18:05:33 SumitNaiksatam: As I've indicated before, I can't make people remove -2s. We need Mark to respond to this and remove the -2 or justify it at this point, and he hasn't done either. 18:05:47 mestery: And also raised on 1-1 email and IRC chats 18:06:13 mestery: my suggestion, and as stated before as well, was never to ask you to ask markmcclain to remove his -2 18:06:15 mestery: Can you, as the PTL, take the action item to follow up on this? 18:06:31 mestery: the suggestion was to find out why the -2 still persists 18:06:45 mandeep: I have already spoken to Mark many times about this to no avail. 18:06:49 SumitNaiksatam: ++ 18:06:59 SumitNaiksatam: That's really the crux, and I haven't had luck in getting that information out. 18:07:13 mestery: okay, we know you have tried 18:07:40 mestery: at this point, and in this forum, we are just trying to find out, from a process perspective, what needs to be done 18:07:56 sorry all - ODL TSC call running late 18:08:01 so I'm here - but not here 18:08:09 so please move my agenda item to near the end 18:08:20 mestery: should there be a "no answer" time limit before the community takes action in these situations? (e.g. voting in the ML so that the PTL removes the -2?) 18:08:21 mestery: alternatively, if there is no process/policy in place for this, we probably need to formulate a reasonable one 18:08:28 ivar-lazzaro: +1 18:08:46 i believe, as a core, i am accountable to the -2 i put 18:09:16 ok... here now 18:09:17 so, if i put a -2, and a new patch set is posted, i review the -2 again 18:09:30 i believe that should be an explicit process that everyone should follow 18:09:38 SumitNaiksatam: you can say that here 18:10:01 SumitNaiksatam: +1 18:10:03 if a new patchset is posted, i think the onus is on the core who put the -2, to justify why it should persist 18:10:16 but since there hasn't been any email on the ML archives, I can't point to any public record of asking for the -2 to be reviewed 18:10:38 there is finally something in the patch set archives, but that's semi-ephermeal 18:10:55 regXboi: there are explicit guidelines to not hound reviewers on the -dev mailing list for reviews 18:10:59 mestery: Do you agree that the process is broken and needs to be addressed? It was also being discussed on the mailing list todayt morning 18:11:05 regXboi: I explicitly asked Mark to either remove or justifiy his -2 in my review where I voted +2. 18:11:13 mestery: http://lists.openstack.org/pipermail/openstack-dev/2014-July/041651.html 18:11:25 rkukura: yes, that's the comment I was referring to 18:11:57 and mandeep: that's a reasonable email 18:11:59 regXboi: We are forbidden to ask for reviews on the mailing list. 18:12:36 regXboi: And that is why we have been sending 1-1 emails to ask for re-review 18:12:53 regXboi: regardless, you cant reason that the -2 persists because there wasnt an email in the mailing list pointing to it, its the duty to of the core to remove the -2 if the circumstances under which he put the -2 have changed 18:12:58 * regXboi notes that rule is not in the interests of transparency 18:13:25 regXboi: I am asking mestery if the process should be updated if multiple teams are hitting similar issues? 18:13:26 SumitNaiksatam: that is not my point at all 18:13:54 my point is that a rule not asking for a re-review on the ML is not in the interests of transparency 18:14:04 okay, we dont intend this to be a meeting where we fix neutorn process/policy issues, i think this team deserves to know why the patch is not allowed to make progress 18:14:14 because my first reaction would be (at this point) to say "d*mn the rules" :-) 18:14:19 but that's me 18:14:21 hence this is being brought up in the agenda here 18:14:51 the hope was that markmcclain would have been able to attend so that he could explain to the team 18:15:06 regXboi: ++, there isn't any concern with sending these types of requests to the mailing list, in fact, in this case, that's where it should be discussed 18:15:20 unfortunately it seems that he is travel 18:15:22 regXboi: And we are asking mestery (PTL) for direction 18:16:18 mestery: so how is asking for a request to review a -2 different from asking for a request to review a patch (the latter is explicitly prohibited) 18:16:52 My point here is that in this case, with a lingering -2, I fail to see how requesting on the list is out of bounds, in fact, it's like a last resort IMHO. 18:17:15 mestery: okay, thanks for that guidance 18:17:35 mestery: that said, this has already been raised in the email that i sent out yesterday 18:17:37 mestery: well, technically they core could ignore the ML thread as well :D 18:18:10 they -> the 18:18:11 ivar-lazzaro: true, but then the weight of public opinion shifts 18:18:47 I had the impression that -2s were a technical issue, not a political one 18:18:59 regXboi: why should we have to waste time in the first place having to build the weight of the public opinion in one way or the other// 18:19:00 regXboi: I hope we are not becoming politicians and responding to public opinion as opposed to technical concerns 18:19:14 mandeep: exactly my point 18:19:17 ok folks, let's be real here 18:19:28 any time you have more than 2 people and money on the table, you have policics 18:19:31 er politics 18:19:51 we need some checks and balances, it seems 18:19:53 ok i will have to reign it here! 18:19:53 even in the perceived optics of the situation there are politics 18:19:57 In terms of policy change - one way to do so may be how contributors can vote for PTL, contributors can also vote for or against cores 18:20:06 SumitNaiksatam: ++ :) 18:20:17 ok so moving on for the time being 18:20:21 all good suggestions 18:20:37 had to allow everyone (including myself) to vent a little! ;-P 18:20:39 s3wong: That is a good idea 18:20:52 s3wong: +1 18:20:58 s3wong: If the public opinion is going to decide it, let the ATC decide it 18:21:08 the other update on the patch series is that all the three series are linear now 18:21:22 that means you can go to GP-PLG-3 and be able to pull everything before it 18:21:44 SumitNaiksatam: Thanks. That helps a lot! 18:21:57 GP-PLG-3 did not pass jenkins because a db migration is dated 18:22:06 but it passes UTs, and should be functional 18:22:29 mestery: before i forget, thanks for stopping by and providing guidance 18:23:07 any questions on series 1, 2, and 3? 18:23:29 other than I have to check that I've got +1s on all of them - no :) 18:23:43 regXboi: thanks ;-) 18:23:49 thanks for reviewing that is 18:24:14 GP-*-1, and GPM-*-1 were rebased until yesterday 18:24:28 GP-*-2/3 need to rebased 18:24:59 #topic Mapping model/driver update 18:25:08 rkukura: over to you, anything new to report here? 18:25:16 with DB migrations in place we will have to rebase often, and that will keep wiping off all the +1s - perhaps gerrit should not wipe out +1s for dbmigration updates 18:25:44 mandeep: that's actually a good point for reviewers - be prepared to do a lot of repeat +1s :/ 18:25:45 mandeep: ah, did not think of that, not sure how easy/difficult it is to achive that 18:25:56 the DB migration for gpm-db-1 was a bit of a challenge, but thanks to HenryG and akamyshnikova, its all worked out 18:26:06 regXboi: thanks for accepting that responsibility! :-) 18:26:24 rkukura: that was great that you were able to fix those issues 18:26:36 SumitNaiksatam: I have been - I've got filters on all the re-review mails so I can hit them first thing in the morning :) 18:26:49 rkukura: any short pointers for the rest of the team here in terms what you did to get around the issue? 18:26:53 regXboi: I agree :-( 18:26:55 I’ll probably include some more validation checks in a gpm-rmd-1 update at some point 18:27:06 regXboi: sounds very organized, great! 18:27:24 One issue was that alembic sometimes does not generate the foriegn key constraints that are in the model 18:28:35 Also, when removing columns in a downgrade, some constraint types need to be removed first, and others don’t 18:28:41 rkukura: ah okay, so you had to manually add those? 18:28:52 Its very easy to test the migrations if you’ve got a devstack environment 18:28:55 rkukura: i mean the foreign key 18:28:56 rkukura: is *that* what that was all about 18:29:28 * regXboi mutters ugly things about code that sometimes does things and sometimes doesn't 18:29:34 for reference, its the DB migration in this patch #link https://review.openstack.org/#/c/101795 18:29:50 I had to manually add the code add and remove foreign keys, and remove the generated code for removing unique constraints 18:30:09 rkukura: ok cool, i guess we can follow that example in the future 18:30:17 rkukura: wouldn't the code be regenerated to remove your manual changes? 18:30:17 akamyshnikova is very helpful on reviewing these, and tested the latest version with postgresql as well 18:30:33 rkukura: sweet 18:30:38 we don’t usually regenerate the migration code 18:30:45 its a generate once, then edit, process 18:30:53 akamyshnikova: much appreciated! 18:30:59 the generated migrations always need some cleanup 18:31:03 rkukura: also the issues that you ran into for generating the migration 18:31:18 rkukura: is the env module change merged upstream? 18:31:47 SumitNaiksatam: Right, not sure if my workaround would still be needed. Hopefully its fixed. 18:32:06 rkukura: ah ok 18:32:32 any questions for rkukura on the mapping part? (since hopefully you are reviewing that right now ;-P ) 18:33:08 So s3wong is making good progress on the next step of the mapping - creating SGs for enforcement of the policy rules. 18:33:23 rkukura: yeah thats next on the agenda item 18:33:38 #topic Security Groups mapping update 18:33:55 s3wong: your turn :-) 18:34:21 So I have been coding up the contract=>SG mapping 18:35:12 so far I coded up the create/update/delete_contract part, and the create/update_EPG part (the latter almost done) 18:35:22 still need to test, get them ready for gerrit 18:35:28 s3wong: okay nice 18:35:29 s3wong: I see you want to defer the question of "which SG is matched" to the drivers, which is fair 18:35:31 also adding unit test as I go along 18:35:46 regXboi: good point to bring up 18:35:49 but that begs the question of how the driver in the patch set will handle that 18:36:10 so at this point, we think that the SG mapping is neutron resource mapping driver specific 18:36:27 SumitNaiksatam: yes I think defering to the drivers is the right answer 18:36:39 but if this includes a sample driver, that has to answer it :/ 18:36:46 regXboi: yes, now it is rendered directly by the mapping driver 18:37:15 regXboi: in terms of patch logistics, this will be a new GPM-RMD-3 patch, right s3wong? 18:37:38 SumitNaiksatam: that's correct 18:37:42 works for me 18:37:50 and I'll be reading when it arrives :) 18:38:16 okay any other questions for s3wong? 18:38:24 so yeah, guys - stay tuned, patches will come soon 18:38:36 s3wong: any blockers for you at this point? 18:38:46 SumitNaiksatam: no 18:39:02 SumitNaiksatam: able to proceed well since you rebased 18:39:22 s3wong: ok good to hear 18:39:30 moving on 18:39:40 #topic CLI/Client 18:39:55 regXboi: we will get to your part in a bit 18:39:58 lets first get the update 18:40:02 songole: there? 18:40:14 yes SumitNaiksatam 18:40:35 Update: posted patches for all GBP resources 18:40:43 tests are pending 18:41:12 Need to handle mapping extension 18:41:27 songole: what are patch numbers? 18:41:53 songole: I have created a couple of public devstack VMs to do integration of the mapping driver, let me know if you need access to that. 18:42:07 https://review.openstack.org/#/c/104013/ 18:42:17 it has dependency links to others 18:42:17 um 18:42:30 that patch doesn't cover anything past -1 18:42:42 when are -2 and -3 going to be added? 18:43:04 regXboi: they are all added 18:43:13 regXboi: https://review.openstack.org/#/c/110798/ 18:43:23 regXboi: https://review.openstack.org/#/c/110806/ 18:43:31 songole: i am not sure i understood “Need to handle mapping extension” 18:43:40 mandeep: thanks 18:43:41 regXboi: (added links for the record) 18:44:01 um... thos patches aren't listed in the wiki?!?! 18:44:04 *those 18:44:20 SumitNaiksatam: end point can take a port, l2 policy could take a network 18:44:30 those options need to be added to CLI-1 18:44:33 songole: oh okay, got it 18:45:05 regXboi: point noted 18:45:22 songole: can you please update the wiki page: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches 18:45:32 mandeep: I will ping on reg those public devstack setups 18:45:39 SumitNaiksatam: will do 18:45:45 SumitNaiksatam, songole: thanks - I've been driving reviews based on that webpage 18:45:55 songole: OK 18:46:02 btw, comment not directed just to songole, anyone if you see the wiki is outdated, please update with your patch link 18:46:05 *links 18:46:12 ++ 18:46:30 regXboi: that was the reason we put the wiki, so you are right in going by that 18:46:37 regXboi: agreed 18:46:57 songole: thats excellent progress, thanks much! 18:47:20 ok now to regXboi’s suggestion 18:47:30 #topic “Profiled” API 18:47:39 regXboi: the floor is yours :-) 18:47:44 folks have probably all seen the email, but let's link it in for the record 18:48:26 the idea is to bring back support for the 2-group approach with minimal intrusiveness 18:48:46 #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/041467.html 18:48:57 regXboi: thanks was just about to post the link 18:49:17 the suggestion is to do this as a patch on CLI-3 (call it CLI-4) because it is a departure from normal openstack convention 18:49:25 and we can go that direction 18:49:45 regXboi: ah cool 18:49:46 with the caveat that we may have to pry open the API to allow the CLI patch to make a single call to neutron 18:50:18 regXboi: That also answer a few questions on what a "profiled API" is, 18:50:20 IIRC the 2-group approach didn't discuss about reuse of policy information, so I have some freedom in trying to make that work 18:50:40 mandeep: the idea of a profiled API come from IETF and other places 18:50:46 * regXboi goes and gets links 18:51:07 regXboi: The patch can also include diffs to other resources (as required), and we can review them as a single change 18:51:10 regXboi mandeep: i am still mystified by the term “profiled”, but i am just ignorant! 18:51:24 examples of what I mean: 18:51:33 OASIS (for SAMLv2): http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf 18:51:41 Encryption and Checksum Specifications for Kerberos 5: http://tools.ietf.org/html/rfc3961 18:51:47 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile: http://www.ietf.org/rfc/rfc3280.txt 18:51:49 regXboi: thanks 18:51:51 regXboi: I am not familiar wit that, but it sounds like an interesting idea. 18:51:53 Internet X.509 Public Key Infrastructure Qualified Certificates Profile: http://ftp.isi.edu/in-notes/rfc3039.txt 18:52:03 regXboi: I will check the link. Thanks. 18:52:08 the point being to define common sets of values for otherwise complex things 18:52:15 regXboi: can you explain what you mean by “we may have to pry open the API” 18:52:26 SumiNaiksatam: sure 18:52:42 SumitNaiksatam: looking at neutron client i do not see any command that leads to anything but a single crud call to neutron. don’t you think departure from that will be difficult? 18:52:54 the issue that may arise is that the CLI is going to make multiple calls to neutron backend 18:53:30 so if folks complain that is uncoventional, we may have to allow the CLI to make a single call and move the profile in to the API side of the patch 18:53:32 banix: yeah, this amounts to some orchestration on the client side 18:53:48 regXboi: CLI is not an orchestrator today. Do you think heat might be a better place to put it? 18:53:52 point folks: HEAT is already doing some orchestration on the client side 18:54:05 songole: no... because that bypasses horizon 18:54:27 regXboi: i think we have some freedom to do the same orchestration in Horizon 18:54:40 that's doing double the necessary work 18:54:44 regXboi: If new orchestration is involved, do you think that we will need do a BP as well? 18:55:02 mandeep: I don't believe so but I don't *know* 18:55:20 i dont think we need a new BP if only client side changes are involved 18:55:21 mestery might have some input here.... 18:55:32 regXboi: Horizon equivalent of orchestration can be a wizard, but if needed it should be able to do the orchestration 18:55:51 mandeep: yeah, thats what i was thinking as well 18:55:51 regXboi: Lets discuss this and see, I don't know off the top of my head 18:55:57 regXboi: But I will need to check if that is being done for now 18:56:03 mandeep: that's not my point - somebody sharp might go "why are you doing this twice?" 18:56:16 mestery: any restrictions on doing some orchestration on the client side? 18:56:17 and we won't have a good answer at that point 18:56:33 mestery: i am not aware that there are, but i dont think that there is a precedent either 18:56:49 SumitNaiksatam: ++, I'm not sure either 18:56:50 * regXboi is known for setting precedents :) 18:57:08 regXboi: i think if its reasonable, there is always a first! 18:57:18 anyway... that's the idea 18:57:29 I was going to say I needed CLI-3 as a starting point 18:57:32 regXboi: okay thanks 18:57:37 but now that is there :) 18:57:55 regXboi: yes we have to thank songole for getting it in expeditiously 18:57:57 regXboi: A quick look at the example profile API links, I would have expected a BP for such a chnage. 18:58:18 regXboi: should CLI be: neutron policy-apply [contract] [src group] [destination group] 18:58:40 LouisF: I think policy-apply will need to change to be consistent with CLI-3 18:58:42 One thing to keep in mind is that the GP API in Juno will be considered experimental, so tweeks to make it more usable in Kilo are certainly possible, even breaking backward compatibility. This CLI approach could be thought of as a temporary workaround. 18:58:55 rkukura: ++ 18:59:10 rkukura: ++ 18:59:14 mandeep: I'm not sure I agree with you, but that's just my opinion 18:59:23 mandeep: regXboi is not suggesting a generic profiled cli; just use of the concept; even that in my opinion it wont get through but i am a bit too cynic at this point 18:59:36 banix: thanks for pointing that out 18:59:40 rkukura: agree 18:59:54 I am *NOT* suggesting a general framework - that's a whole different kettle of fish 19:00:00 I'm talking about a one off 19:00:01 banix: Thanks for the clarification 19:00:33 regXboi: But hopefully a one-off that sets a precedence for other similar updates ... ;-) 19:00:34 regXboi: it sounds perfectly reasonable to me suggest this approach in a patch 19:00:36 anyway - we're at the top of the hour - any more questions? 19:00:51 SumitNaiksatam: +1 19:00:54 regXboi: thanks for that update and clarification 19:00:55 I left a comment at #link https://review.openstack.org/#/c/103755/ a few days ago on Patch Set 3; i think regardless of what Ryan is suggesting this should be trivial to do; do you guys see any reason why it cannot be done? 19:01:08 banix: sorry i missed that 19:01:09 and if I'm not here - reply to the thread on the ML 19:01:20 banix: until you pointed out in the email thread 19:01:23 banix: i will respond 19:01:44 #topic API Intercept 19:01:54 * regXboi pads away 19:01:56 just a quick plug for the work kevinbenton has been doing #link https://review.openstack.org/#/c/109901 19:02:09 #topic Open Discussion 19:02:21 we will need to wrap up quickly since we are over 19:02:32 we did not touch on the vendor drivers today 19:02:37 I’ve started looking at the intercept patch, but need to spend more time to understand it. 19:02:46 but hopefully people are thinking about it and are not overly blocked 19:02:50 Same here 19:03:00 rkukura mandeep: thanks 19:03:02 +1 19:03:18 rms_13: any quick update on Horizon? 19:03:32 horizon integration that is 19:03:36 Not today. For sure next thursday as I am going to work full time on it tomorrow 19:03:49 rms_13: nice, looking forward to it 19:03:49 Abishek is going to do initial glance 19:03:56 rms_13: okay 19:04:13 rms_13: you might want to look at songole’s new patches 19:04:24 Yes. That is going to change my current patch 19:04:44 alright anything else, anyone? 19:05:11 alright, thanks all for joining 19:05:17 bye 19:05:19 by 19:05:21 bye 19:05:24 bye 19:05:25 until next week, but please keep reviewing 19:05:29 rms_13: has horizon ptach been updated? 19:05:30 bye 19:05:38 bye 19:05:45 #endmeeting