18:01:41 #startmeeting networking_policy 18:01:42 Meeting started Thu Oct 2 18:01:41 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:45 The meeting name has been set to 'networking_policy' 18:01:59 #info agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy 18:02:26 banix mentioned earlier that he cannot make it due to personal reasons 18:02:48 hope everything is fine at his end 18:02:59 yes, banix will likely miss some more meetings, and possibly the K-Summit 18:03:15 #chairs s3wong ivar-lazzaro ivar-lazzaro rms_13 rkukura kevinbenton 18:03:31 Hi 18:03:47 #topic StackForge Process 18:04:48 so i believe most of us have been pretty busy either pushing code to the stackforge repos or reviewing the patches 18:05:10 just wanted to take a minute here to make sure that everyone is in sync with the process we are following 18:05:39 essentially the process is that same as was with Neutron or any other OpenStack project 18:06:15 we create the blueprint in Launchpad: #link https://launchpad.net/group-based-policy 18:06:41 then submit a spec for review in gerrit: #link http://git.openstack.org/cgit/stackforge/group-based-policy-specs 18:07:12 once spec is reviewed, approved and merged, we push patches for review: #link http://git.openstack.org/cgit/stackforge/group-based-policy 18:07:29 make sure you mention the blueprint ID in the implementation patches 18:07:54 also, bugs should be reported here: #link https://bugs.launchpad.net/group-based-policy 18:08:54 there is no deviation from the standard process, just need to be aware of the relevant launchpad projects and the git repos 18:08:57 any questions? 18:09:00 SumitNaiksatam: great! 18:09:12 SumitNaiksatam: sounds good 18:09:24 SumitNaiksatam: Thanks for the recap 18:09:27 ivar-lazzaro: thanks for boostrapping the gbp repo! 18:09:29 Good stuff 18:09:34 rms_13: s3wong: sure 18:10:01 #topic Summary of relevant links for code and specs 18:10:17 I have been trying to capture everything in this one page: #link https://wiki.openstack.org/wiki/GroupBasedPolicy/StackForge/repos 18:10:26 please feel free to edit and/or correct 18:10:45 the idea was to provide a dashboard kind of a view 18:11:15 since we have a number of repos to deal with 18:11:35 that brings to the next topic on reviews 18:11:41 #topic Patches in review 18:11:50 #link https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy+branch:master,n,z 18:12:03 we have a large number of patches in review now 18:12:25 also the above link is for the server side patches 18:12:39 there are patches in review in the client heat and horizon as well 18:12:57 requesting you to please review the patches at the earliest 18:13:14 anything that we need to discuss about the current patches? 18:14:13 SumitNaiksatam: no cli patches? 18:14:33 yeah, see my earlier comment :-) 18:14:57 s3wong: cli patches: #link https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy-client+branch:master,n,z 18:15:14 SumitNaiksatam: which is "none" 18:15:36 doh! 18:15:44 not sure what happened there 18:16:18 s3wong: corrected link: #link https://review.openstack.org/#/q/status:open+project:stackforge/python-group-based-policy-client+branch:master,n,z 18:16:29 i will fix the wiki (repo name was wrong) 18:16:54 i need to fix the UTs on this patch 18:17:01 SumitNaiksatam: cool --- that makes more sense. Hard to believe we have Heat and Horizon patches but no neutron-python-client :-) 18:17:12 s3wong: :-) yeah my bad 18:17:32 i spent quite a bit of time on this, but still the UTs are failing 18:17:46 the issue is with trying to eliminate duplication code from neutron client 18:17:48 anyway 18:18:01 any thoughts questions on the reviews? 18:18:52 okay moving on 18:19:17 our favorite topic - 18:19:24 #topic Resource renaming - finalize 18:19:30 SumitNaiksatam: did you see my comments on groupbasedpolicy.py? 18:19:36 #undo 18:19:37 Removing item from minutes: 18:19:48 LouisF: on the client? 18:19:51 yes 18:20:21 LouisF: i did notice that you had commented, however i was caught up with fixing the UT issue 18:20:30 SumitNaiksatam: ok 18:20:31 LouisF: i mean to address the comments after i get the UTs to run 18:20:41 LouisF: apologies for the delay 18:20:46 SumitNaiksatam: np 18:20:46 LouisF: and thanks for the review 18:20:58 : #topic Resource renaming - finalize 18:21:05 #topic Resource renaming - finalize 18:21:46 so to recap, in this meeting we had earlier agreed to rename Endpoint -> Policy Target, and Endpoint Group -> Policy Target Group 18:22:09 there are a couple of other changes that were proposed in the past, and we discussed last week 18:22:11 SumitNaiksatam: +1 18:22:16 Contract -> Policy Rule Set 18:22:22 SumitNaiksatam: oops, I just merged the API-1 patch without these terminology/naming changes :-) 18:22:36 * Contract -> Policy Rules Set 18:22:44 s3wong: no worries 18:22:49 s3wong: it's ok, I think it's better to apply those changes on top anyway 18:22:52 s3wong: we did not mean to change the names right away 18:22:57 ivar-lazzaro: +1 18:23:14 and Policy Labels -> Policy Tags 18:23:26 SumitNaiksatam, ivar-lazzaro: sure :-) I didn't expect them anyway 18:23:36 so anyone object to Policy Rules Set, and Policy Tags ? 18:23:54 SumitNaiksatam: I preferred contract 18:24:08 LouisF: okay, and i know rkukura preferred that as well 18:24:32 SumitNaiksatam: so do I 18:25:09 LouisF: however lots of people also prefer Policy Rule Set, their justification being that since Contract is a collecton of Policy Rules, so Policy Rules Set is more intuitive 18:25:15 s3wong: ^^^ 18:25:46 to some extent we also socialized this new terminology in the Policy Summit 18:25:51 though Policy-Rules-Set gives rkukura another chance to make another acronym in PRS 18:25:53 and i did not hear any pushback 18:26:10 s3wong: absolutely! :-) 18:26:25 for the record, i personally prefer our older terminology, but anyway 18:26:58 so i understand that we have preferences, but is there any objection to Policy Rule Set and Policy Tags? 18:27:07 SumitNaiksatam: i'm ok if that is a majority decision 18:27:37 okay so can we have a show of hands at least here, if people are okay with the renaming? 18:27:48 ivar-lazzaro: rms_13 hemanthravi ? 18:27:57 s3wong: ? 18:28:07 Fine by me 18:28:13 SumitNaiksatam: +1 18:28:13 ok with me 18:28:20 sandr8: ;-P 18:28:21 SumitNaiksatam: I am OK with it --- just finalize so we don't do this over again :-) 18:29:04 s3wong: exactly, we cant be in this limbo, since we have quite a few things to catch up on in terms of implementation 18:30:02 SumitNaiksatam: contract is a stronger concept than prs 18:30:20 LouisF: agree 18:30:56 LouisF: would you strongly object to PRS though? 18:31:17 just a -1 18:31:26 LouisF: :-) 18:32:17 okay lets do this, lets send this out to the ML today, and see if anyone has objections, and if not we can roll with this (perhaps a bit reluctantly) 18:32:20 LouisF: sound okay? 18:32:28 SumitNaiksatam: ok 18:32:37 okay thanks all 18:33:11 end of meeting already? 18:34:18 s3wong: the end of the model renaming discussion is a great milestone per se :) 18:34:20 #agreed tentative agreement in the team to rename resources to Policy Rules Set and Policy Tags (will move forward if there are no further major objections) 18:34:30 ivar-lazzaro: :-) 18:34:50 ivar-lazzaro: well, i see a "thanks all" -- which is usually an indicator that the meeting is over :-) 18:35:18 btw, i think based on the merging of the first patch, we seemed to have decided that we will implement the renaming as a follow up 18:35:37 s3wong: ivar-lazzaro: good catch :-) , we still have a few more agenda items 18:35:53 SumitNaiksatam: my apology as I was the one giving it the second +2 (and workflow +1) :-) 18:36:17 s3wong: no worries, that was actually the thinking (at least in my mind) 18:36:21 SumitNaiksatam: though I did put a question there somewhere asking if we want to do renaming on the patch 18:36:21 s3wong: so no harm done 18:36:39 s3wong: Subrah had put the question 18:36:45 i saw that 18:37:00 #topic Cross project dependency on neutron package 18:37:19 so the issue is that we are currently referring to a neutron package in our requirements 18:37:42 and this is currently in the form of a pypi package that ivar-lazzaro has created 18:37:58 rkukura had suggested that we replace this with a pointer to the neutron repo 18:38:18 however, ivar-lazzaro tried it but couldnt get it to work 18:38:35 ivar-lazzaro: please correct me if i am wrong, just trying to quickly summarize here 18:39:03 beyond that, my suggested is to actually remove this from the requirements.txt and put it in the test-requriements.txt 18:39:08 or else it breaks the devstack install 18:39:25 SumitNaiksatam: I think moving the requirement in test-requirements should be fine as long as neutron is installed always before GBP 18:39:42 SumitNaiksatam: which will happen anyway 18:39:44 ivar-lazzaro: true 18:39:57 SumitNaiksatam: so if everyone is fine I'll go ahead and change it 18:40:04 ivar-lazzaro: okay 18:40:35 ivar-lazzaro: as i was mentioning, the requirements seem to get processed twice and that creates duplicate entrypoints 18:40:54 ivar-lazzaro: as soon as i removed the neutron package from the requirements, the issue went away 18:40:59 SumitNaiksatam: yeah makes sense 18:41:40 it would be helpful if someone from this team has prior experience on the packaging stuff, and if so please reach out to either me or ivar-lazzaro or rkukura 18:41:52 #link DB migrations 18:42:02 oops 18:42:10 #topic DB migrations 18:42:20 ivar-lazzaro: you want to summarize the issue? 18:42:27 SumitNaiksatam: sure 18:42:44 So as is now, we are running our migration on top of Neutron's 18:43:08 By doing this, we are changing the HEAD value on alembic_version table in the neutron Database 18:43:43 Problem is, when your version is polluted in this fashion you will be unable to upgrade Neutron anymore 18:44:12 so if you are using Neutron Juno + GBP, you won't be able to migrate to Kilo without some manual steps (downgrading GBP for instance) 18:44:22 ivar-lazzaro: nice summary! 18:44:51 Long story short, I would like create a separate DB schema for our project... Which will share the same connection 18:45:18 so the options on the table are (as summarized by rkukura): “Do we use separate DBs with separate chains? Do we use separate chains in the same same DB? Does the GBP migration chain always effectively splice to the end of the neutron migration chain, or do they need to somehow be interleaved?” 18:45:35 ivar-lazzaro: yeah that is one of the options (perhaps the only viable one right now) 18:45:52 SumitNaiksatam: there are other viable and maybe faster options 18:46:06 btw, I forgot to mention earlier, rkukura had a doctor’s appointment, so he could not join today 18:46:18 SumitNaiksatam: but they don't solve the main problem 18:46:24 ivar-lazzaro: okay 18:46:57 HenryG: hi 18:47:10 SumitNaiksatam: for instance, in alembic is possible to configure a different version table. With Neutron and GBP having different version tables the problem is mitigated 18:47:20 o/ 18:47:32 HenryG: sorry for pinging you out of the blue 18:47:38 HenryG: but thought that it might interest you 18:47:39 SumitNaiksatam: np 18:47:55 SumitNaiksatam: but even in this case, if in the future Neutron tries to create a table named gp_endpoints everything will break again 18:48:05 HenryG: if you back scroll to the current topic on “DB migrations” in the context of our stackforge GBP effort 18:48:14 HenryG: would love to hear your input 18:48:26 ivar-lazzaro: true 18:48:36 HenryG: we can discuss offline 18:49:02 any other DB migration gurus out there, would love to get your input 18:49:22 ivar-lazzaro: thanks again for the summary and trying to work through this tricky issue 18:49:33 SumitNaiksatam: np 18:49:48 Will GBP be packaged separately from neutron? 18:49:53 #topic refactoring of resource mapping driver 18:49:56 HenryG: yes 18:50:25 HenryG: at least for Juno, since its not in the trunk 18:50:53 on the topic of resource mapping driver, per rkukura: “What should be factored out of the resource_mapping driver for use by other drivers?” 18:51:28 so anyone writing GBP vendor drivers, please reach out to rkukura with thoughts on this 18:51:35 SumitNaiksatam: I have a couple of suggestions on this matter 18:51:35 or just start an email thread 18:51:42 ivar-lazzaro: yes sure 18:52:05 rms_13: you will be writing GBP driver as well, right? 18:52:12 SumitNaiksatam: first we should gather all the useful and possibly common code out of the resource mapping driver to a more generic superclass 18:52:27 ivar-lazzaro: yes, we had discussed that earlier as well 18:52:46 ivar-lazzaro: i believe the suggestion is that we do this after the current patches merge? 18:52:47 SumitNaiksatam: and then we should probably think of a way for each driver to define their own mapping 18:52:58 ivar-lazzaro: okay 18:53:02 SumitNaiksatam: that I always give for granted :D 18:53:04 ivar-lazzaro: lets start an email thread on this 18:54:10 SumitNaiksatam, ivar-lazzaro: for this, rkukura and I talked about it during the hackathon 18:54:24 s3wong: yes 18:54:36 okay so it seems like lots of people have ideas 18:54:42 he thinks EPG, L2/3-policy, implicit drivers are items that should be fairly common across all the vendors 18:54:44 might require more offline discussion 18:54:56 SumitNaiksatam: can you copy me on that 18:54:58 s3wong: implicit driver, yes 18:55:05 and he wants to factor out that from the contract mapping piece and make it into another mapping driver 18:55:08 LouisF: yes sure, the whole team 18:55:22 obviously, as we discussed, I couldn't do it before Juno feature freeze 18:55:37 s3wong: yeah, no 18:55:42 *np 18:55:43 but in my mind, I believe rkukura would want to put that as an item for Kilo cycle 18:55:52 s3wong: implicit is definitively common, but each plugin may want its own resource mapping 18:56:45 L2Policy mapping to Neutron network, and L3Policy mapping to a router --- even in case of non-implicit, seems useful for more than one driver 18:57:18 ivar-lazzaro: I definitely see that contract=>SG mapping to mostly NOT be too useful for most vendors :-) 18:57:34 s3wong: ivar-lazzaro: good points 18:57:48 s3wong: even l2_context -> network or anything else.... Endpoint -> Port is the only one I feel is mandatory 18:57:50 since rkukura is not around, lets going to the ML for this 18:58:05 SumitNaiksatam: +1 18:58:10 SumitNaiksatam: sure 18:58:13 ivar-lazzaro: s3wong thanks 18:58:17 #topic Open Discussion 18:58:23 anything we missed? 18:58:54 rms_13: we need to start porting code to the GBP Horizon repo 18:59:08 rms_13: we will have help on this, but it will help to get your reviews 18:59:20 rms_13: among other things ;-) 18:59:32 anything else folks? 19:00:07 okay thanks everyone for joining 19:00:11 thanks 19:00:14 keep up the good work! 19:00:15 Ciao! 19:00:20 #endmeeting