19:01:09 #startmeeting networking_policy 19:01:10 Meeting started Thu Mar 6 19:01:09 2014 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:13 The meeting name has been set to 'networking_policy' 19:01:48 * mestery thinks meetbot appears slow today, perhaps an ominous sign. 19:02:03 :) 19:02:03 #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy Agenda 19:02:06 hi all! 19:02:19 SumitNaiksatam: Hi sumit 19:02:22 SmitNaiksatam: hi 19:02:23 hello 19:02:30 hi everyone 19:02:34 #topic Action Item Review 19:02:38 s3wong: Hi 19:02:38 banix s3wong mandeep hi 19:02:45 Greetings everyone! 19:02:52 Lets walk through action items from last week's meeting now. 19:02:54 First up: 19:02:55 SumitNaiksatam and prasadv to update document to add contracts to Object Model 19:03:04 Any updates on this one? 19:03:18 yeah 19:03:24 sumit do you want to update 19:03:26 prasadv: sure 19:03:37 we haven't updated the main document yet 19:03:58 prasadv hemanth mandeep and I got together and brainstormed 19:04:07 we made progress 19:04:08 Awesome! 19:04:20 but still work to be done 19:04:23 #link https://docs.google.com/a/noironetworks.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g1c910cf8b_038 19:04:35 Cool, thanks SumitNaiksatam for the update! 19:04:35 hence we did not add to the document 19:04:40 OK 19:04:43 happy to discuss here 19:05:08 prasadv: you want to add? 19:05:28 you summed it pretty well 19:05:32 SumitNaiksatam: shouldn't action be a list? 19:05:44 that is, one classifier to n actions? 19:05:45 so is "policy" more like "policy rule" we had earlier 19:05:53 s3wong: hmmm…yeah it was a list before 19:06:11 s3wong: but what is an example of multiple actions? 19:06:19 banix: yeah 19:06:22 also - policy should have more than one {classifier: list of actions} 19:06:30 with contract essentially being the "policy" in the terminology we have been using? 19:06:42 banix: yes thats the idea 19:06:46 s3wong: ^^^ 19:07:25 SumitNaiksatam: there are several different action types. For example, it can be 'allow', then 'redirect' to a mirror, then set some 'qos' action 19:07:33 all off of one classifier match 19:07:48 s3wong: can we think of that as a composite action? 19:08:05 s3wong: with a list, you get into priority issues 19:08:16 Agree on the priority issue front here. 19:08:35 s3wong: Yes, were trying to use a white list model that did not need priority 19:09:07 s3wong: But this is still work in progress, and this is good input 19:09:08 SumitNaiksatam: actions are quite orthogonal though - also, some type does not make sense to have multiple, for example 'security' 19:09:33 but OTOH, 'qos' action type can have multiple actions 19:09:34 s3wong: yeah, we thought if we can could collapse multiple actions into one 19:09:45 s3wong: yeah 19:09:59 but yeah, like mandeep said, not set in stone 19:10:01 SumitNaiksatam: the endpoing group mapping to a neutron network is just the default value, right? because it is defined in the BP doc that it can be either a network or port 19:10:13 cgoncalves: Yes 19:10:22 we still need to work further on action(s) 19:10:23 cgoncalves: yes for the former, no for the latter 19:10:28 SumitNaiksatam: how is actions represented then? 19:10:46 s3wong: we will need to have an extensible set of defined actions 19:11:13 cgoncalves: port is an endpoint 19:11:26 cgoncalves: peg is a collection of end points 19:11:38 *epg 19:11:40 cgoncalves: A neutron network identifies a group of endpoints with "default neutron policy", but a group could exist with a different membership 19:12:22 SumitNaiksatam: I do agree we shouldn't have priority on the set of actions 19:12:23 SumitNaiksatam, mandeep: ok, thanks for clarifying :) 19:12:31 and an peg can contain endpoints and one single network? 19:12:31 and that was never the intention anyway 19:12:44 * mestery thinks peg may be sticking now ... :) 19:12:52 :) 19:12:56 ;-) 19:13:08 what is peg? :-) 19:13:14 policy endpoint group 19:13:28 spell correct tries to invent new terms and i like to take credit :-) 19:13:36 peg -> epg 19:13:43 sorry 19:13:59 IIRC we have been using different terminology in different places (e.g., 'connectivity group' in the BP, 'endpoint group' in BD and/or DB (not sure right now)) 19:14:13 cgoncalves: Good pint 19:14:23 cgoncalves: we will normalize 19:14:26 cgoncalves: We need to fix this in the doc update 19:14:31 cgoncalves: thanks for catching that 19:14:32 just use peg :-) 19:14:34 SumitNaiksatam: agreed 19:14:36 SO I think as we proceed a bit but not too far we should take the discussion to the google doc as we did earlier 19:14:54 banix: +1 19:14:54 cgoncalves: make comments on the doc if you see inconsistencies ;-) 19:14:58 and for the neutron CLI I've used as is in the BP, i.e. 'connectivity group' 19:15:05 banix: I agreed. We should be commenting on the doc a lot 19:15:05 banix:+1 19:15:21 banix: yes sure 19:15:21 that was the working model before 19:15:30 SumitNaiksatam: we must first defined which one to use. either connectivity group or endpoint group 19:15:47 s/defined/define 19:15:57 I think we had been using endpoint group for a long time 19:16:02 so should i replace the current diagram with the one i posted in the link above? 19:16:06 Let us stay with the terms we agreed on earlier unless there is a need to change 19:16:29 though we used "connectivity group" in both the API doc and the actual API implementation :-) 19:16:53 At various points, we've used both terms. 19:17:05 What should we settle on then? 19:17:17 let us not get hung up on names ... let us take that discussion to the doc 19:17:28 end point group seems more natural to me 19:17:36 Good call mandeep, didn't mean to resolve here either. :) 19:17:36 I think even though our work is independent of ODL effort along the same direction, 19:17:36 since its a collection of end points 19:17:37 +1 for end point group 19:17:40 mandeep: sorry 19:18:02 mandeep: i agree, not get hung up on names :-) 19:18:09 we can use similar terms to avoid confusing everybody later on; just a suggestion 19:18:28 banix: I agree, we should stay consistent with ODL model where applicable 19:18:38 banix: agreed - in ODL we settled on the project being call GBP (group-based policy) 19:18:38 +1 to staying consistent with ODL model 19:18:42 * cgoncalves thinks we will settle for 'endpoint group', but moves on the subject :-) 19:18:50 and the official term for the group is endpoint group 19:19:08 so if we are going with the ODL terminology, we should go with endpoint group 19:19:12 or e.g. (as in egg) 19:19:30 sorry, lets move on 19:19:44 +1 for consistency 19:20:31 so for the model, all of us will make our comments on doc? 19:20:35 is that the next step? 19:20:51 s3wong: Yes, that was my understanding 19:20:53 Makes sense to me s3wong. 19:21:04 s3wong: which doc? 19:21:06 those working on the first draft, need a bit time to add more? 19:21:23 to the doc i meant 19:21:34 SumitNaiksatam: the google preso doc you sent above 19:21:54 s3wong: OK 19:21:56 "Neutron Group Policy Model" 19:22:05 s3wong: ok 19:22:07 This one: https://docs.google.com/a/noironetworks.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g1c910cf8b_00 19:22:09 Right? 19:22:30 mestery: yeah that was the one i pasted earlier 19:22:33 ok got it 19:22:38 mestery: correct, the one that starts with "Work In Progress!!!" 19:22:48 banix: we do need more time to add more, right sumit? 19:22:52 #action Group Policy members to comment on the document here for next week https://docs.google.com/a/noironetworks.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g1c910cf8b_00 19:23:03 prasadv: yeah 19:23:17 prasadv: Yes 19:23:19 OK, lets hit the second Action Item for review 19:23:26 From last week: mandeep to setup neutronclient shared repo 19:23:31 done 19:23:38 Awesome! Thanks mandeep! 19:23:41 Updates the meeting minutes with the repo 19:23:44 mandeep: thanks! 19:23:48 Perfect, thanks! 19:23:52 #topic Plugin status update 19:23:58 SumitNaiksatam? 19:24:05 I've pushed code to branch cgoncalves/group-policy 19:24:14 mestery: yeah 19:24:17 cgoncalves: Sweet! 19:24:34 i pushed code as well :-) 19:25:00 Sweet! 19:25:05 cgoncalves: thanks; can you say bait about what it does 19:25:05 not to get too excited - an initial post on the plugin 19:25:20 SumitNaiksatam: cool! 19:25:28 banix: thanks 19:25:33 too late, we are already excited :) 19:25:38 hahahahah 19:25:46 * mestery thinks the group policy team is easily excitable. 19:25:53 "-) 19:25:54 :) 19:25:55 :-) 19:26:07 so this was after a bit of experimentation 19:26:09 banix: it's just a first draft of commands and API calls. will have to be refactored to keep up with the latest models changes 19:26:21 there is some insight gained 19:26:30 i see; will look; thanks. 19:26:35 we agreed that we would be doing a single plugin 19:26:48 which would be configured as a "core" plugin 19:26:58 Yes 19:27:05 OK 19:27:07 the "core" configuration part of it is a bit tricky 19:27:24 since we still want to use the L3, L3, services plugin 19:27:50 so what i am doing in the patch is, you still configure all other plugins as before 19:28:05 so ML2 still gets configured as "core_plugin" 19:28:22 then we introduce an additional piece of configuration for the policy plugin 19:28:28 call it an interceptor 19:28:55 so now, the neutron plugin loading mechanism loads all the plugins as before (including core) 19:29:05 then we introduce a hook for this interceptor 19:29:08 SumitNaiksatam: Reminds me of what Broace/Vyatta was proposing in Hong Kong :) 19:29:20 ok 19:29:28 i hope i don't step on their terminilogy 19:29:33 it might mean different things 19:29:35 Nope, not at all. 19:29:37 Yeah, true. 19:29:42 mestery: yeah, the Geoff Arnold dynamic resource mgmt thingy 19:29:42 if the interceptor is configured 19:29:48 s3wong: Exactly! 19:30:16 then, the loaded references to the core and other plugins are replaced with the interceptor/policy-plugin 19:30:27 and those references will be passed to the policy plugin 19:30:56 now the policy plugin is in the path of all the calls (which is what we want) 19:31:06 That sounds pretty nice SumitNaiksatam! 19:31:23 what this does is, it allows us to stay consistent with wherever "core_plugin" is used 19:31:24 SumitNaiksatam: would that break the non-policy Neutron calls? 19:31:28 say for example devstack 19:31:48 we just become and additional/optional configuration 19:32:05 so i hope i have managed to confuse everyone by now! :-) 19:32:09 Cool; Looking forward to seeing the code. 19:32:16 :) 19:32:28 i have run into an issue with the way the extensions are loaded 19:32:34 SumitNaiksatam: Cool. 19:32:36 so the current patch is breaking at that 19:32:37 we are an excitable easily confused bunch :) 19:32:39 but working on it 19:32:45 banix: hahaha 19:32:50 great thanks. 19:33:13 open to questions comments on this 19:33:15 SumitNaiksatam: sounds great to me! 19:33:15 SumitNaiksatam: I think that's the way to go, even later on. replacing ML2 with yet another core plugin is troublesome for sysadmins. we would also have to come up with a migration tool if ML2 that's deprecated; or am I understanding the ML2-replacement wrong? 19:33:21 rkukura: thanks 19:34:00 s/that's/gets 19:34:03 cgoncalves: so in this scheme, i don't think they will have to change their references to the core_plugin (ML2 that is) 19:34:06 SumitNaiksatam: so this is an infra to get interceptor loaded - my guess is this interceptor is meant to be generic, not only for policy (other projects that need to intercept calls can use it in the future too)? 19:34:18 cgoncalves: there will be additional config (which might required migration) 19:34:25 s3wong: Correct, say for debugging 19:34:27 SumitNaiksatam: exactly, in this scheme such wouldn't be required 19:34:32 s3wong: exactly 19:34:51 but we have to be careful with setting the expectations on migration :-) 19:35:02 SumitNaiksatam: just wanted with my previous comment that this way of introducing group policy as an interceptor is better in the long run I think 19:35:06 i mean from a legacy to a group policy based system 19:35:12 SumitNaiksatam: They have to work ... 19:35:16 cgoncalves: true true 19:35:50 very good 19:36:14 * cgoncalves is excited to have a working, even if minimal, group policy + redirect setup flowing 19:36:26 SumitNaiksatam: This is very encouraging work! Awesome! 19:36:39 mestery: sure 19:36:59 cgoncalves: a fair bit to go before that 19:37:08 Any other questions/discussions on the plugin? 19:37:09 sumitnaiksatam: very good work!! 19:37:19 prasadv: thanks 19:37:19 prasadv: +1 19:37:20 SumitNaiksatam: I know, I know :) 19:37:25 I can only imagine how much testing is needed before this patch can make it upstream :-) 19:37:41 s3wong: :P 19:37:48 s3wong: ha good one 19:37:55 Great Sumit. thanks. 19:37:57 s3wong: you're no fun! hehe 19:37:59 so thats what i mean by setting the expectations 19:38:19 i think there is a huge overhead even for a tiny change 19:38:25 Yeah, good call. 19:38:34 so we have to sandbox accordingly 19:38:51 i think most of us have experienced that in icehouse :-) 19:38:57 not funny actually 19:39:25 * s3wong sighs 19:39:34 True 19:39:44 Do we want to bring this approach to the larger community; not now but may be later on when we make more progress? 19:39:58 banix: oh absolutely 19:40:09 May be part of what we discuss at the sumit 19:40:11 banix: yeah, that was my question above actually :-) 19:40:12 banix: lets get it work to a reasonable extent 19:40:19 yes makes sense 19:40:29 banix: with some UTs 19:40:41 banix: but i agree better to socialize sooner than later 19:41:03 Yes, will have much more time to work on this after the ongoing deadlines are passed 19:41:12 SumitNaiksatam: correct, probably want to give a heads up on the ML once this works to a certain extent 19:41:17 banix: sure 19:41:25 s3wong: yes sure 19:41:49 i think the best thing will be to post on gerrit at the earliest 19:42:11 +1 to that SumitNaiksatam 19:42:55 sounds good 19:43:45 OK, lets move on then. 19:43:48 #topic Model 19:43:54 I guess we talked bout this a lot already. 19:43:58 Anything else to discuss here now? 19:44:08 16 more minutes!!! 19:44:20 :) 19:44:29 I mean, object model discussions. 19:44:39 We did this earlier I think. Anything else to ponder further? 19:44:51 We had started discussing connection to services framework 19:45:03 banix: yeah 19:45:04 banix: that will happen on a separate meeting, no? 19:45:09 banix: This is true, yes. We had decided to move that out right SumitNaiksatam? 19:45:13 Yes 19:45:15 separate meeting I think 19:45:29 Wednesdays @1900 UTC 19:45:30 mestery: yeah, we thought we had enough fires to fight for icehouse 3 19:45:32 banix: Yes 19:45:43 and daylight saving time will come for us US people 19:45:43 yes i agree 19:45:44 :) 19:45:49 so next wednesday works for everyone? 19:45:56 wanted to say something else: 19:46:01 * mestery will be on vacation, but please proceed without me. :) 19:46:08 i am ok 19:46:09 SumitNaiksatam: sure, works for me 19:46:20 ok 19:46:27 ok will talk later. 19:46:46 #topic Open Discussion 19:46:51 Anything else this week then? 19:47:12 banix: you were saying something 19:47:32 yeah, waiting for banix to finish his something else :-) 19:47:33 no i just wanted to say we could have a basic framework that does not require services 19:47:53 as such and we can have that as a separate complementary but not necessary thing. that's all. 19:47:55 banix: for PoC, sure, we should keep it simple 19:47:55 banix: Yes, that could a first phase 19:47:57 banix: yes, we can incrementally evolve 19:48:14 exactly; that was it from my side. 19:48:29 only thing is that we have certain requirements down the line, we need to start planning now 19:48:39 it takes a really long time to get anything in 19:48:48 especially resource/api changes 19:49:03 yeah, the group-policy meeting can hopefully focus more on actually coding and PoC 19:49:11 I agree. 19:49:18 and the service meeting will focus on doing service with group-policy 19:49:19 +1 19:49:38 yeah, we don't have much time left for the PoC 19:50:06 Looks like we have violent agreement ;-) 19:50:09 good thing is we don't rely on neutron reviewers to accept the PoC :-) 19:50:12 consensus!!! 19:50:52 Great job starting the ball rolling 19:51:06 Yes, nice work SumitNaiksatam! 19:51:18 mestery: thanks, good team work 19:51:28 +1 19:51:37 OK, if there's nothing else, lets call this meeting 9 minutes early! :) 19:51:45 excitable team is a great thing! 19:51:51 :) 19:51:53 :) 19:51:57 mestery: sure thanks! 19:51:59 All good 19:51:59 let's pat ourselves on the back for early meeting ending and tremendous aggreement overall :) 19:52:01 excited about leaving early! 19:52:01 Thanks for everyone's help and excitement! 19:52:06 ;) 19:52:07 cgoncalves: +1 19:52:09 #endmeeting