18:01:42 #startmeeting networking_policy 18:01:43 Meeting started Thu May 8 18:01:42 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:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:46 The meeting name has been set to 'networking_policy' 18:01:55 #info agenda https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy 18:02:03 #topic GP bp spec review 18:02:12 #link https://review.openstack.org/#/c/89469 18:02:27 this was merged 18:02:43 thanks all for contributing and working towards this 18:02:57 an important milestone in the process 18:03:22 SumitNaiksatam: great. thanks to you for all your work as well 18:03:37 banix: thanks, great team effort 18:03:44 so we have to transition to the next step for pushing the patches 18:03:53 hi 18:04:03 rkukura: hi 18:04:16 we are obviously already working towards that 18:04:18 SumitNaiksatam: hi 18:04:23 mandeep: hi 18:04:30 our PoC is a step in that direction 18:04:51 lets first touch quickly on the model 18:04:57 #topic Policy Model 18:05:07 we made some minor tweaks 18:05:20 i am referring to the EPG to Contract relationship change 18:05:32 most of you already know this 18:05:36 just reiterating here 18:06:03 the ContractProvider/ConsumerScope is now optional when specifying the relationship 18:06:37 so you can say EPG X consumes/provides Contract Y (without having to create the relationship object) 18:07:05 this probably makes it much simpler and easier to incrementally consume this model 18:07:24 I agree 18:07:43 banix: thanks, yeah i mostly heard everyone in agreement with this change 18:07:56 so a contract can consume a list of EPGs? 18:08:13 Louis_: er…its the other way around 18:08:14 Yes, agreed 18:08:18 mandeep: ok 18:08:33 Louis_: EPGs can consume one or more Contracts 18:09:23 ok, just wanted to highlight that change 18:09:42 if no other thoughts/questions, then moving on 18:09:44 ok, so a EPG can provide one or more contracts? 18:10:00 Louis_: yes (and/or consume one or more contracts) 18:10:32 we lost SumitNaiksatam 18:10:33 is this shown in an updated model diagram? 18:10:58 Let us wait for SumitNaiksatam to join 18:11:02 is this shown in an updated model diagram? 18:11:03 sorry, i got bumped out 18:11:13 Louis_: yes 18:11:41 Louis_: see: https://docs.google.com/a/noironetworks.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit?pli=1#slide=id.g1d6aae2d8_5651 18:11:54 and: https://docs.google.com/a/noironetworks.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit?pli=1#slide=id.g12c5a79d7_4044 18:13:14 Louis_: looks okay? 18:13:52 Louis_: perhaps we can come back to this 18:14:13 #topic PoC Status Update 18:14:25 #info PoC branch is: https://github.com/noironetworks/neutron-group-policy/tree/group-policy-poc 18:14:40 we are full steam ahead on this 18:15:00 yesterday we created the first EPG and EP! 18:15:03 yay! 18:15:07 +1 18:15:14 baby steps 18:15:18 amazing 18:15:25 thanks all 18:16:00 so as of now, EPG, EP, Contract, Policy Rule, Policy Classifier, and Policy Action resources are implemented 18:16:12 this is what we will have in the first iteration 18:16:17 It was a significant integration across devstack, python-neutronclient + CLI, group-policy manager + plugin, ... so a good ene-toend flowe 18:16:23 also BD and RD 18:16:25 mandeep: +1 18:16:33 rkukura: yes, thanks! 18:16:47 rkukura: i only keep thining about the app guy! :-P 18:16:53 *thinking 18:17:18 SumitNaiksatam: need to do a bit more of that myself ;) 18:17:22 ok i see the provided_contracts/consumed_contracts list in the EPG REST table 18:17:39 rkukura: we need the balance :-) 18:17:50 Louis_: yes 18:18:07 on the model implementation, there are things which are not tested yet 18:18:14 like the Contract hierarchy 18:18:19 still not on gerrit :p 18:18:29 marun: getting there :-) 18:18:36 that should be the first step, not the last. 18:18:48 I guarantee patch review is going to be more complicated by this path. 18:19:00 But, sometimes lessons need to be learned the hard way :) 18:19:28 marun: well its not yet ready for gerrit yet, there are many moving peices and we are in teh process validating how well the peices fit 18:19:40 marun: hence this is called a PoC 18:19:55 disagree entirely 18:20:06 but we can agree to disagree 18:20:08 marun: we dont want to waste reviewers cycles on things which are not baked 18:20:14 'waste time'? 18:20:17 you mark it as 'WIP' 18:20:18 marun: absolutely 18:20:27 or 'DRAFT' 18:20:51 working outside of gerrit limits visibility to the subteam, and that's not a good thing. 18:21:01 it also encourages monolithic changes without oversight. 18:21:02 marun: disagree 18:21:11 all of which will bite in actual review 18:21:19 as you will see soon enough :) 18:21:31 marun: We could push the whole thing as a single WIP review on gerrit, but will probably want to push the real code in smaller chunks for review 18:21:33 marun: that sounds more like a threat! 18:21:42 take it as you will 18:21:58 marun: not a very constructive to phrase it 18:22:01 ok moving on 18:22:05 I hold all feature additions to the same standards. 18:22:32 marun: as does everyone else here 18:22:43 If only! 18:22:48 rkukura: over to you on the mapping implementation 18:23:24 rkukura: can you give a two line brief description of the mapping work if you don’t mind 18:23:35 rkukura: great progress on the keeping in sync with the model changes 18:24:43 ok 18:24:59 basically, the mapping does two things now: 18:25:35 first, if an EPG is created without passing in a BD, one is implicitly created for the EPG 18:26:31 similarly, if a BD is created (implicitly or explicitly) and no RD is passed in, a default RD for the tenant is created/found 18:27:20 second, the RD is mapped to a neutron router, the BD is mapped to a neutron network, the EPG is mapped to a neutron subnet, and the EP is mapped to a neutron port 18:28:06 so we were able to use the GP API to create an EPG, create an EP in it, and then get a port for EP and use it to launch a nova VM 18:28:14 thanks rkukura for the summary 18:28:20 that’s basically where the mapping stands 18:28:51 we’re starting to work on mapping the policy to SG and FW rules 18:29:17 also some aspects of the mapping are configuration driven 18:29:23 rkukura: great summary 18:29:42 why is there a 1-1 binding and a many-many association between a RD and a router? 18:29:45 the BD and RD are created implicitly. right? at least that is the desired workflow? 18:30:07 banix: yes 18:30:16 banix: either implicit or explicit BR and RD creation should work 18:30:31 banix: however its possible to provide them explicitly as well 18:30:42 Louis_: Right now, I think the mapping will use one router per RD 18:30:43 ok thanks 18:30:53 Louis_: RD to routers is 1:many 18:31:15 would be good to know if we really need multiple routers in a single RD 18:31:35 i see in the code there is both a binding and an association 18:31:37 rkukura: there might be use cases 18:31:45 Louis_: good question 18:32:00 Louis_: we want to remove the association 18:32:09 we allow multiple subnets per EPG in order to support adding more EPs than one subnet will hold 18:33:22 rkurkura: certainly makes it easier for me to just fetch the router via context 18:33:42 agreed we should remove both association tables from the DB model if we can 18:33:54 rkukura: yeah 18:34:29 any more thoughts/questions on the mapping? 18:34:38 s3wong: Unless we have a use case for the PoC, I think we should limit the PoC to one router per RD 18:34:46 just a general question on the model: 18:34:51 rkukura: yes, agree 18:34:52 wouldn't it be better to remove the binding? 18:34:56 rkukura: and I do not disagree with that :-) 18:35:06 we had discussed this early on but not recently. what is the connectivity within an EPG? 18:35:19 and just have the association? 18:35:40 Louis_: its actually not a many:many to relationship 18:35:57 Louis_: RD to routers, that is 18:36:12 s3wong: do you see an immediate need for multiple routers in the same RD? If so, we should talk about how we decide which one(s) the EPG’s subnets get connected to, which I’m working on today 18:36:51 rkukura s3wong: i think in the implicit workflow, one router is good 18:36:54 rkukura: no, there isn't. We should focus on getting contract done. One per RD is definitely good for PoC 18:37:07 banix: EPs within EPG have connectivity 18:37:39 SumitNaiksatam: they do in our implementation but in the model? 18:38:03 banix: this behavior can be overriden by setting attributes in teh BD 18:38:26 s3wong: I see now that you said “I do not DISAGREE with that”, which I read as “I do not AGREE with that” 18:38:33 banix: yes, that is the current default semantics in the model as well 18:38:51 rkukura: sorry - should have cap-lock the word :-) 18:38:51 rkukura: two negatives :-) 18:39:25 banix: any concerns with those semantics? 18:39:26 need to take it easy on us native English speakers ;) 18:39:28 SumitNaiksatam: ok we can disucss more later 18:39:43 rkukura SumitNaiksatam: my crooked English... :-( 18:39:54 s3wong rkukura: :-) 18:39:56 I just need to read more carefully 18:39:57 SumitNaiksatam: not a big concern but in general the app developer expectation may be different 18:40:14 banix: ok, any examples? 18:40:30 SumitNaiksatam: app servers in a tier may not need talking to each other 18:40:56 banix: ok 18:41:38 so the proposal was to put attributes in the BD, which can define that behavior 18:41:49 banix: As I recall, SGs have an implicit rule allowing all traffic within the subnet. Not sure if we’d be able to use the existing SG API to limit this. 18:42:38 SumitNaiksatam: i think in the model we may want to have the default as no connectivity but i realize in the mapping driver we may not be able to do that 18:42:46 rkukura: yes i understand 18:43:36 banix: we can probably have attribute in the BD, like “ISOLATED” (probably not a a good name) 18:43:51 banix: and its setting can be driven by configuration 18:44:00 sure let’s discuss at the summit or after the summit 18:44:20 banix: if the default BD creation is with this attribute set, then we can support that behavior 18:44:34 banix: that way we dont ahve to set it for the ref impl 18:44:37 banix: ok 18:44:47 SumitNaiksatam: ok 18:44:48 rkukura: thanks! 18:44:52 for the update 18:45:05 s3wong: over to you for the service integration 18:45:31 Working on the code now. Couple things I want to raise here, to ensure I am on the right path 18:46:08 (1) since the API is REDIRECT -> [the actual service UUID]. I don't see a need to add anything on the mapping db 18:46:27 s3wong: agree (at least for PoC) 18:46:49 so what it amounts to would be writing out the create_policy_action_postcommit 18:46:50 s3wong: well let me take that back 18:47:00 SumitNaiksatam: yes? 18:47:11 s3wong: how would we undo the action, when we remove the contract? 18:47:40 s3wong: never mind, that will still work, becaue the uuid will still be in the contract 18:47:41 SumitNaiksatam: for now? update_firewall to disable it from router 18:47:54 and yes, the UUID would still be in the db 18:47:58 s3wong: sorry, you are right, i think it will work 18:48:14 (just not the mapping db) 18:48:56 (2) this is really question for SumitNaiksatam: is update_firewall the right call to enable FW? 18:49:08 s3wong: yes 18:49:39 my understanding (via reading FW code yesterday) is, there is one instance of FWaaS per tenant 18:49:59 s3wong: one can also enable at the granularity of the rule level (but not needed here) 18:50:05 so it would automatically be enable on all the routers belonging to the tenant? 18:50:07 s3wong: yes, one per tenant 18:50:28 s3wong: i think default might be that its enabled by default 18:50:58 s3wong: but while creating the firewall, i think you can set the admin state to be down 18:51:31 s3wong: so although the firewall is there on each router, its not enabled 18:51:41 SumitNaiksatam: OK - so it case the policy_action is removed, I just set the admin state of the FW to down to remove the redirect action? 18:52:25 s3wong: wouldn’t that effect all traffic for the tenant, not just traffic for that one action? 18:52:34 but what of mulitple contracts use that FW instance? 18:53:10 s3wong: yes, the iptables rule should get removed 18:53:11 rkukura: yes - unfortunately we need to complete the work of service insertion and steering to change this behavior 18:53:28 Louis_: i think for now only one contract using the fw is ok 18:53:40 Louis_, rkukura: yes as s3wong mentioned, this has much broader scope 18:53:46 agree for the poc 18:53:51 the current discussion is in teh context of the PoC 18:53:52 Louis_: for PoC, I think it is fine 18:53:54 Louis_: yesh 18:54:09 Louis_: And we need to get started in parallel with the services work that is also still in discussion 18:54:30 mandeep: yes 18:54:39 mandeep Louis_: with pretty much the same people in that subteam :-) 18:54:43 Louis_: thats a whole other discussion that is happening in parallel 18:55:02 s3wong: :-) 18:55:50 s3wong: At least marun will be happy that it is not a monolithic change 18:56:07 :) 18:56:12 ok moving on 18:56:21 #topic CLI and Client 18:56:32 Hemanth made greate progress 18:56:35 *great 18:56:41 he could not attend today 18:56:58 banix followed that up with quick progress as well 18:57:00 banix would have to proxy hemanthravi :-) 18:57:15 banix: thanks for jumping in yesterday and pushing out the patch yesterday night 18:57:20 +1 That was phenomenal, first pass integration ;-) 18:57:32 +1, thanks banix 18:57:53 sure 18:58:01 will there be irc meeting next week? 18:58:16 Louis_: no meetings next week 18:58:32 #announcement no Group policy IRC meeting next week 18:58:48 before s3wong demands that it be made official :-P 18:58:53 thanks mandeep for the cue! 18:58:56 but there is design session at summit 18:59:00 Louis_: yes 18:59:25 design summit session discussion is on the agenda 18:59:39 but we have not gotten to it 18:59:46 one minute to our next meeting :-) 18:59:56 got distracted with some unnecessary discsussions earlier! 19:00:12 is ronak here? 19:00:19 perhaps not. 19:00:28 we probably have to yield to the next meeting 19:00:35 so lets call it a wrap 19:00:50 thanks all for the awesome work 19:00:57 see you at the summit next week 19:01:04 safe travels! 19:01:09 #endmeeting