18:01:59 <SumitNaiksatam> #startmeeting networking_policy
18:02:00 <openstack> Meeting started Thu May 22 18:01:59 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:04 <openstack> The meeting name has been set to 'networking_policy'
18:02:19 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
18:02:43 <mandeep> banix: Hi
18:02:54 <SumitNaiksatam> firstly, thanks to everyone for the participation in the during the summit
18:03:18 <SumitNaiksatam> more so to the team which actually worked on the PoC, great effort in pulling it together across projects in record time
18:03:24 <rkukura> hi
18:03:36 <SumitNaiksatam> needless to say, it was very well received
18:04:02 <marun> uh
18:04:07 <mandeep> Great work by SumitNaiksatam rkukura hemanthravi prasadv ronak rudrarugge
18:04:12 <s3wong> yes, it was. banix, SumitNaiksatam, and me were mobbed after the presentation
18:04:32 <SumitNaiksatam> s3wong: true
18:04:33 <banix> i think it is fair to say the public at large was very supportive of the direction
18:05:08 <mandeep> banix: Yes, I was viewing the presentation - very well done banix s3wong and SumitNaiksatam
18:05:09 <banix> that is the need for policy abstractions
18:05:10 <marun> I've sent an email to os-dev that paints a somewhat contradictory viewpoint.
18:05:20 <SumitNaiksatam> okay to the first topic on the agenda
18:05:23 <mandeep> (and I should have added banix and s3wong to my last list ;-)
18:05:47 <mandeep> When did you send it marun
18:05:53 <marun> just now I'm afraid.
18:05:53 <mandeep> I did not see that
18:05:58 <mandeep> OK
18:06:00 <SumitNaiksatam> ok lets follow the agenda items
18:06:05 <s3wong> marun: really?
18:06:18 <SumitNaiksatam> so that we can get all items covered
18:06:29 <marun> I've added an item to the end of the agenda to discuss.
18:06:29 <banix> marun: we are mainly referring to the need for policy abstractions and not specifically a particular model and approach etc
18:06:33 <marun> so yes, let's move on.
18:06:38 <SumitNaiksatam> marun: good
18:06:40 <mandeep> As it is just seconds before the meeting, we can not discuss to that I guess.
18:06:52 <SumitNaiksatam> i will just go based on the order currently in the agenda
18:06:59 <SumitNaiksatam> #topic Change of weekly meeting time
18:07:23 <regXboi> banix added that at my request
18:07:24 <SumitNaiksatam> i thought we had good consensus on this time/day?
18:07:31 <mandeep> Yes
18:07:32 <SumitNaiksatam> regXboi: ah ok
18:07:37 <mandeep> We finally got the meeting slot!
18:07:38 <regXboi> problem is that this overlaps with the ODL TSC which is 2 hours
18:07:46 <banix> conflicting with TCM at ODL
18:07:50 <SumitNaiksatam> regXboi: actually we bounced off a few meetings times in the past
18:07:50 <banix> TSC
18:07:59 <regXboi> and several of the TSC members (myself included) are obligated to that
18:08:03 <regXboi> and can't participate in this
18:08:06 <SumitNaiksatam> and it was difficult to find an open openstack channel
18:08:14 <mandeep> regXboi: We have tried quite a few slots and this is already the 3rd or 4th attempt
18:08:33 <mandeep> I would rather not chnage it again, if possible
18:08:39 <s3wong> SumitNaiksatam: perhaps pushing it earlier? I have a three hours slot between LBaaS and GP
18:08:55 <regXboi> mandeep: you are basically saying to TSC folks that are also working ODL GBP "go away"
18:09:27 <regXboi> but, I understand the problem with finding a good time
18:09:31 <banix> regXboi: Starting one hour later would work?
18:09:36 <SumitNaiksatam> regXboi: we should definitely try to accomodate every one to the extent possible
18:09:41 <regXboi> starting one hour later would work
18:09:43 <mandeep> My morniong is also filled up, then I guess I will go away?
18:09:52 <s3wong> regXboi: I simply stopped attending the TSC meeting - but I can see you wouldn't be able to do that, as a TSC member :-)
18:09:54 <banix> SumitNaiksatam: any chance we switch fwaas and this one?
18:09:56 <prasadv> one hour later will not work for ODL GBP folks
18:10:03 <banix> if others are ok with it that is
18:10:04 <regXboi> um
18:10:08 <regXboi> yes it will
18:10:23 <s3wong> prasadv: correct, I suggested earlier
18:10:40 <prasadv> s3wong: earlier works
18:10:46 <regXboi> is this a 60 minute or a longer irc?
18:11:02 <SumitNaiksatam> banix: if we replace with fwaas, we will have two back-to-back heavy meetings (the former one is advanced services)
18:11:10 <SumitNaiksatam> regXboi: this meeting is 60 min
18:11:15 <regXboi> if it's 60 minutes, there is a window between the end of this slot and the GBP ODL
18:11:23 <regXboi> er ODL GBP
18:11:26 <banix> SumitNaiksatam: yeah confused the dates
18:11:42 <regXboi> and to mandeep's point - I can't go earlier in the day
18:11:52 <regXboi> I'm blocked solid until when this slot ends
18:12:05 <mandeep> And I know that prasadv and hemanthravi travel after this call to the ODL call
18:12:12 <regXboi> ah
18:12:16 <regXboi> travel is an issue
18:12:22 <prasadv> we travel to the meeting most of the time
18:12:23 <regXboi> I'm remote to all of them...
18:12:27 <s3wong> regXboi: travel as in 10 minutes drive :-)
18:12:38 <banix> prasadv: you are very dedicated :)
18:12:45 <regXboi> longer than sub-minute irc->hangout/webex flip
18:12:54 <SumitNaiksatam> okay, so lets bounce off some times off line
18:13:03 <SumitNaiksatam> regXboi: any chance the ODL meeting can be moved?
18:13:05 <regXboi> sure... in the meantime, I can load up banix
18:13:14 <regXboi> SumitNaiksatam: no
18:13:18 <SumitNaiksatam> regXboi: being optimistic :-)
18:13:18 <regXboi> it's a 2-hour slot
18:13:24 <banix> regXboi: np; will try to find a better time.
18:13:30 <regXboi> thanks all
18:13:47 <SumitNaiksatam> #topic PoC status update
18:14:19 <SumitNaiksatam> so while we achieved most of what we set out to do for the PoC, there were a few loose ends
18:15:09 <SumitNaiksatam> our patches are in review in gerrit, but some people in the team will continue to focus on tying those loose ends
18:15:22 <SumitNaiksatam> rkukura s3wong you want to fill on that?
18:15:24 <regXboi> those loose ends being?
18:15:38 <SumitNaiksatam> regXboi: on cue ^^^ :-
18:15:47 <s3wong> rkukura: want to go first?
18:15:49 * regXboi can play the straight person
18:15:57 <rkukura> sure
18:16:54 <rkukura> We had hoped to get the PoC to the point where the mapping driver was setting up neutron security groups to actually enforce some policy rules, but did not get that far.
18:17:28 <LouisF> any work planned for redirect action?
18:17:43 <rkukura> Right now, the mapping driver manages the neutron networks, subnets, port, and routers, with all access allowed. The security groups would let us deny traffic that is not explciity allowed.
18:17:46 <s3wong> LouisF: that's me. It will be next after ruukura :-)
18:18:16 <banix> LouisF: hi Louis, good to see you here
18:18:25 <rkukura> There are also some issues with allocating subnets from withint the RD’s supernet that need fixing.
18:18:29 <LouisF> good to meet at summit
18:19:18 <rkukura> So I thinkk it makes sense to continue to work towards these goals in the PoC/github code base in parallel with the work to merge lower layers to neutron’s repository.
18:19:37 <s3wong> rkukura: my turn?
18:19:50 <SumitNaiksatam> rkukura: thanks
18:20:04 <rkukura> SumitNaiksatam: Did you want me to mention some of the design changes we’ve been thinking about for the driver and driver API?
18:20:08 <rkukura> or is that later?
18:20:59 <s3wong> OK - for the PoC, due to ease of unit testing and several pieces absence during my time of integration test, the redirect action takes place upon policy-action creation
18:21:04 <SumitNaiksatam> rkukura: thats a different agenda item
18:21:22 <s3wong> which isn't the right place, so the first thing I will do for post-PoC is to move it to contract creation, where it belongs
18:21:52 <s3wong> Second, to properly do redirect to a service (UUID), we need ServiceBase Object support, whose bp is already in gerrit
18:22:10 <s3wong> and coincidently, I (along with kanzhe) will be working on that
18:22:37 <s3wong> so to implement 'redirect' action properly on the mapping driver, that ServiceBase effort is a bit of a dependency
18:22:53 <LouisF> will ServiceBase be added to the POC branch?
18:23:26 <SumitNaiksatam> LouisF: service base is intended to get the adavanced services framework going
18:23:38 <SumitNaiksatam> LouisF: so it has applicability beyond group policy
18:23:39 <s3wong> LouisF: good question. In terms of checking in, the 'redirect' mapping driver part will obviously be after the ServiceBase work
18:23:52 <SumitNaiksatam> LouisF: hopefully that will go in soon
18:23:55 <s3wong> in terms of PoC branch, I think porting it there for unit testing purpose makes sense
18:24:04 <songole> s3wong: is the redirect action specified on a rule or inside contract?
18:24:05 <s3wong> but won't be part of the check-in, of course
18:24:26 <s3wong> songole: redirect action, like all actions, is part of policy-rule
18:24:28 <banix> songole: rule
18:24:57 <s3wong> that's it for me
18:25:13 <SumitNaiksatam> s3wong: ok thanks
18:25:28 <SumitNaiksatam> any questions for rkukura or s3wong in terms of the above update?
18:25:32 <songole> s3wong: got it. thanks
18:26:04 <SumitNaiksatam> $topic Gerrit reviews
18:26:10 <LouisF> what branch is ServiceBase work on?
18:26:28 <rkukura> SumitNaiksatam: use #topic
18:26:29 <SumitNaiksatam> Policy Model: #link  https://review.openstack.org/#/c/93853
18:26:39 <s3wong> LouisF: kanzhe and I will fork from Neutron to work on it - we are working on that now
18:26:46 <SumitNaiksatam> Mapping Driver #link https://review.openstack.org/#/c/93935
18:27:13 <SumitNaiksatam> #topic  Gerrit reviews
18:27:18 <SumitNaiksatam> rkukura: thanks :-)
18:27:26 <SumitNaiksatam> above links dont change
18:27:36 <s3wong> LouisF: if you are interested, please join us at the advanced service IRC meeting Wed 17:30 UTC on #openstack-meeting-3
18:28:02 <SumitNaiksatam> so the first patch only has two resources now, and is the first in a series
18:28:26 <SumitNaiksatam> the second patch is WIP, and is waiting for a few more patches to land on the model side
18:28:28 <LouisF> hmm nobody on channel yesterday
18:28:46 <SumitNaiksatam> but the second patch should give a good idea about the mapping driver implementation
18:29:12 <SumitNaiksatam> hopefully you all can review and provide constructive feedback
18:29:16 <rkukura> The 2nd will also be broken up into smaller patches when its dependencies are ready
18:29:32 <s3wong> LouisF: really? I was there yesterday, as were SumitNaiksatam, banix, kanzhe, rkukura, and many others...
18:29:34 <SumitNaiksatam> rkukura: thanks
18:29:59 <SumitNaiksatam> LouisF: yes, we had the meeting yesterday (was a full house)
18:30:19 <SumitNaiksatam> any thoughts questions on the gerrit patches in review?
18:31:05 <banix> we are trying to breakdown the patches to smaller pieces so the review process is easier; is this being helpful?
18:31:16 <regXboi> I'll admit that I'm late to the party
18:31:48 <SumitNaiksatam> banix: yeah good point
18:32:32 <SumitNaiksatam> ok perhaps it is helpful, since no counter opinions
18:32:40 <SumitNaiksatam> #topic Mapping driver
18:33:10 <SumitNaiksatam> so rkukura wanted to spend a little bit of time on some the discussions around this topic
18:33:22 <rkukura> ok
18:33:23 <SumitNaiksatam> rkukura: i believe you had a few items on the agenda
18:34:16 <markmcclain1> SumitNaiksatam: had to step away for sec, but do have questions on the reviews
18:34:28 <SumitNaiksatam> #undo
18:34:28 <rkukura> One question that came up during PoC implementation was whether the code that implicitly creates BDs and RDs when they are not passed in explicitly might not really be specific to the mapping driver, so maybe it should go in the plugin itself.
18:34:29 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x380fe90>
18:34:37 <SumitNaiksatam> rkukura: one sec
18:34:40 <SumitNaiksatam> markmcclain1: go ahead
18:35:16 <markmcclain1> SumitNaiksatam: even with the smaller patches it is impossible to review because the code series doesn't actually work
18:35:43 <SumitNaiksatam> markmcclain1: not quite sure, what you mean by code series doesnt actually work?
18:35:52 <mandeep> markmcclain1: Please explain.
18:36:02 <rkukura> SumitNaiksatam, markmcclain1: Unit tests should pass, right?
18:36:10 <SumitNaiksatam> rkukura: yes they do
18:36:17 <markmcclain1> functionally it should work
18:36:28 <markmcclain1> UT should pass per chunk
18:36:37 <SumitNaiksatam> markmcclain1: there is only patch in the series right now
18:36:38 <mandeep> And the entire policy can not be made to work with out all the policy objects being in place
18:36:48 <SumitNaiksatam> markmcclain1: not sure what your expectation is
18:36:54 <mandeep> As requested by marun the patches are being split by resources
18:36:58 <SumitNaiksatam> markmcclain1: an entire functional patch was posted
18:37:04 <SumitNaiksatam> markmcclain1: you refused to review it
18:37:14 <SumitNaiksatam> markmcclain1: becuause you wanted it broken down
18:37:15 <marun> SumitNaiksatam: I pointed out why it was a problem weeks ago.
18:37:17 <SumitNaiksatam> markmcclain1: you got that
18:37:27 <mandeep> So the patches are now split
18:37:29 <markmcclain1> but I should be able to grab the last in a series and actually run the extension and see changes to datapath
18:37:41 <SumitNaiksatam> markmcclain1: there is only in the series
18:37:43 <rkukura> We’re breaking it up both by layers and by resources
18:37:45 <SumitNaiksatam> markmcclain1: the others are coming
18:37:53 <markmcclain1> right the nice thing about breaking into patches is that code can be reviewed in chunks
18:38:01 <markmcclain1> but for functional testing the end result can be run
18:38:28 <SumitNaiksatam> markmcclain1: sure, so you want that all patches be posted before you start reviewing?
18:38:36 <mandeep> And we do not expect you to approve the patches until they fit together in a function chunk
18:38:56 <markmcclain1> yes otherwise we're just looking at one tree at a time to figure out what the forrest looks like
18:39:19 <rkukura> That sounds nice in theory, but would basically force doing all the development outside the OpenStack gerrit environment, wouldn’t it?
18:39:35 <marun> rkukura: Quite the opposite
18:39:37 <mandeep> But the "tree" can be inspected for code issues and UTs etc
18:40:00 <SumitNaiksatam> markmcclain1: yes, exactly for that reason there is also a PoC branch that be pulled and tested in entirety
18:40:27 <mandeep> SumitNaiksatam: exactly
18:40:51 <markmcclain1> gerrit will sequence the commits correctly
18:41:03 <banix> so i think we agree that the code will be rather large. So the question is how best we go about doing this in steps so the review can be done effectively.
18:41:04 <SumitNaiksatam> markmcclain1: absolutely
18:41:35 <mandeep> markmcclain1: Can I request that we chnage the discussion on - how can we make progress on it vs. why it can not work the way it is?
18:41:36 <marun> As per my email, there is some question as to whether the proposed approach is actually the way forward in the short term.
18:41:57 <rkukura> There is a lot of boilerplate and common patterns involved. We’ve been hoping to get closure on these on a small subset of resources, before putting all the othe resources into review. This seems to be a lot more efficient use of reviewers’ time.
18:42:07 <mandeep> marun: I can not discuss that without having read it.
18:42:12 <marun> then go read it.
18:42:20 <SumitNaiksatam> rkukura: thats a good point
18:42:21 <mandeep> I will. After this IRC
18:42:32 <marun> sure.  then you won't be able to actually speak to my points.
18:42:43 <marun> I started participating late in the game, and if i had known there was a simple approach, I would have pushed for it.
18:42:44 <mandeep> I will respond on the ML
18:42:46 <markmcclain1> rkukura: you're right there is boilerplate
18:42:54 <banix> marun: yes, just read your email: #link http://lists.openstack.org/pipermail/openstack-dev/2014-May/035666.html
18:42:59 <marun> 'the simplest thing that can possibly work' is generally the best thing.
18:43:04 <prasadv> marun: can we discuss one topic at a time.. first can we resolve checkin and resolution process
18:43:06 <SumitNaiksatam> for anyone who actually read through the patch, it is indeed very boilerplate
18:43:08 <marun> especially when pushing new initiatives.
18:43:11 <markmcclain1> but the whole reason we started requiring implementations with APIs was because the lbaas API was so terrible
18:43:24 <markmcclain1> nobody really noticed until they tried to use it
18:43:27 <mandeep> Yes, I want to avoid religious discussions as well.
18:43:39 <mandeep> Let us focus on how to structure the checkin
18:44:07 <SumitNaiksatam> okay, so let me stop this topic here
18:44:21 <SumitNaiksatam> i think the expectation for some of the reviewers is that more patches land
18:44:21 <marun> mandeep: To be blunt, the question that needs to be answered is 'are we solving the right problem'
18:44:28 <SumitNaiksatam> before they get a better feel
18:44:36 <marun> Rather than 'are we solving the problem right'
18:44:45 <mandeep> marun: We can discuss that independly of what the questions are on the current check-in
18:44:47 <SumitNaiksatam> so lets do that (which I believe was the plan any way)
18:44:57 <SumitNaiksatam> markmcclain1: does the address your concern as well?
18:45:04 <mandeep> marun: So that later if you undertsand that what we are doing is correct we would not have wasted time
18:45:29 <SumitNaiksatam> marun mandeep: can i request you to hold your horses a bit
18:45:39 <mandeep> SumitNaiksatam: OK
18:45:43 <SumitNaiksatam> there is a topic in the agena, we can take it up at that time
18:45:50 <banix> are there horses here?
18:45:54 <banix> :)
18:46:08 <mandeep> SumitNaiksatam: But I would prefer to get an answer on how to strcutre the patches
18:46:28 <SumitNaiksatam> mandeep: i think we have agreement that patches are structured in the right way
18:46:29 <mandeep> SumitNaiksatam: Do we have agreement on what would be acceptable
18:46:38 <SumitNaiksatam> mandeep: just that more patches need to land
18:46:38 <mandeep> SumitNaiksatam: Cool
18:46:50 <markmcclain1> SumitNaiksatam: yes ideally more functional units and if there is a logical way to separate them so that we don't get a series that's 20 deep that would be nice
18:46:58 <mandeep> SumitNaiksatam: In that case, I am Ok to move on to the next phase
18:47:34 <SumitNaiksatam> markmcclain1: you can either have smaller chunks, and but more patches, or bigger chunks with less patches :-)
18:47:49 <SumitNaiksatam> markmcclain1: i believe you wanted smaller chunks, in a series
18:47:55 <markmcclain1> I want both :)
18:47:56 <mandeep> markmcclain1: Policy is a big item, you can not just solve a part of it
18:48:15 <SumitNaiksatam> markmcclain1: well you will need to teach us to bend the laws of physics then
18:48:16 <marun> mandeep: no comment
18:48:17 <markmcclain1> mandeep: fully aware.. just making sure that we have good items to test
18:48:30 <mandeep> markmcclain1: Either that, or as a community we are not going to sign up to solving big problems
18:48:31 <markmcclain1> the lbaas experience from 2 yrs ago still haunts
18:48:47 <rkukura> markmcclain1: Would building things up like we did in the PoC effort help - getting first the to where the Endpoint and EndpointGroup resources can be used as an alternative to directly using neutron resources first, the adding policy/contract/enforcement to this, help?
18:48:56 <marun> mandeep: there are more than 1 ways to skin a cat
18:49:26 <markmcclain1> rkukura: that does seem like something that could prove workable
18:49:37 <markmcclain1> ie a series that gets us to Endpoints/Groups
18:49:56 <mandeep> marun: I challenge you to show ONE real life policy based service deployment system that is "small"
18:49:56 <SumitNaiksatam> markmcclain1: ok we should be able to endpoints and groups in less than 20 patches :-)
18:50:07 <markmcclain1> SumitNaiksatam: cool
18:50:10 <marun> mandeep: I challenge you to find a single workable system that wasn't developed incrementally.
18:50:22 <marun> (in open source)
18:50:39 <mandeep> marun: This has been developed incrementally - week after week - you joined the party late
18:50:49 <marun> mandeep: incrementally outside of oversight
18:51:00 <SumitNaiksatam> ok good, i think we have good agreement on the current approach, we need to get to the point where we have the EP and EPG in review soon
18:51:00 <mandeep> marun: There was oversight
18:51:07 <marun> mandeep: not from the wider neutron community
18:51:10 <SumitNaiksatam> so we wil get to taht
18:51:15 <SumitNaiksatam> markmcclain1: sound okay?
18:51:18 <mandeep> marun:  the whole team worked on an open repo tigether
18:51:34 <rkukura> marun: There has been an official neutron subteam working on this during the entire icehouse cycle, reporting at the neutron IRC meetings
18:51:35 <markmcclain1> SumitNaiksatam: from a review perspective yes
18:51:36 <marun> mandeep: the fact that we're dealing with things like patch structure point to a failure to understand how to contribute to neutron
18:51:37 <mandeep> marun: With oversignt from multiple neutron cores
18:51:58 <SumitNaiksatam> ok moving back to the earlier topic
18:52:03 <SumitNaiksatam> #topic Mapping driver
18:52:05 <marun> nothing that can't be remedied, but pretending it's not a problem seems pretty silly
18:52:07 <mandeep> marun: You know better than other cores, obviously
18:52:14 <marun> mandeep: really?
18:52:16 <markmcclain1> SumitNaiksatam: thanks for indulging my review process questions
18:52:20 <rkukura> the PoC is just that, trying to prove some concepts before submitting code for formal review
18:52:37 <mandeep> markmcclain1: Thanks for the clarification
18:52:59 <SumitNaiksatam> markmcclain1: always
18:53:47 <rkukura> back to the current topic…
18:53:53 <SumitNaiksatam> rkukura: please
18:54:03 <rkukura> One question that came up during PoC implementation was whether the code that implicitly creates BDs and RDs when they are not passed in explicitly might not really be specific to the mapping driver, so maybe it should go in the plugin itself.
18:54:11 <SumitNaiksatam> rkukura: maybe a short summary, so that we can to get the other items as well
18:54:42 <rkukura> So I’m looking into putting that into a separate driver that runs before the mapping driver.
18:55:21 <SumitNaiksatam> rkukura: i like that idea
18:55:35 <s3wong> rkukura: +1
18:55:41 <regXboi> so um hold
18:55:45 <SumitNaiksatam> rkukura: will this be in the PoC branch?
18:55:46 <rkukura> Will also make a meaningful chunk for review ;)
18:56:00 <regXboi> I'm still a little unclear how bridge and router domains come into this discussion?
18:56:01 <s3wong> rkukura: :-)
18:56:28 <SumitNaiksatam> regXboi: that was the next topic on the agenda
18:56:39 <SumitNaiksatam> #topic Resource name changes
18:56:39 * regXboi plays straight man again
18:56:42 <regXboi> ok I can wait :)
18:56:58 <SumitNaiksatam> regXboi: it seems that BD and RD names are causing a lot of confusion
18:57:12 <SumitNaiksatam> and are being interpreted for what they are not
18:57:23 <rkukura> regXboi: These need to be their for the mapping driver to do its thing, but the APIs would used more from an application network admin role than an application deployer role.
18:57:43 <mandeep> SumitNaiksatam: Propose change names to L3-policy-context and L2-policy-context
18:57:53 <regXboi> mandeep: +1
18:58:02 <prasadv> mandeep: +1
18:58:07 <s3wong> mandeep: +1
18:58:08 <SumitNaiksatam> mandeep: yeah something like that will be good
18:58:20 <rkukura> Some risk of confusion around the work “context” since its used in the driver API (based on ML2’s similar pattern)
18:58:34 <SumitNaiksatam> lets think a little more on this (since these are just meant to hold context attributes)
18:58:42 <SumitNaiksatam> ok moving on
18:58:48 <rkukura> But L?PolicyContext is fine with me
18:58:54 <SumitNaiksatam> want to make sure give time for marun’s agenda item
18:59:02 <SumitNaiksatam> #topic Summit session post-mortem
18:59:10 <s3wong> 2 minutes? :-)
18:59:21 <SumitNaiksatam> we can go a little over unless we get kicked out
18:59:22 <marun> armax: has suggested on the ml thread to schedule an ad-hoc meeting to discuss
18:59:29 <SumitNaiksatam> (but hopefully not a neverending debate)
18:59:31 <mandeep> s3wong: I can sacrifice my luch to hear this
18:59:41 <armax> yeah just a minute is not gonna cut it
18:59:41 <armax> :)
18:59:44 <marun> And that would give folks a chance to read it.
18:59:46 <regXboi> I'm in for the long haul
19:00:09 <banix> sounds reasonable
19:00:13 <marun> So, no need to extend, we can schedule something later.
19:00:31 <mandeep> SumitNaiksatam: Will you be scheduling this ad-hoc meeting?
19:00:44 <SumitNaiksatam> sure,
19:00:47 <regXboi> and more to the point: "how" will the meeting get scheduled?
19:00:50 <SumitNaiksatam> we can have another meeting :-)
19:00:51 <marun> I'm off tomorrow and all next week, but I'd suggest collecting participants from the ml thread and discussing the issues raised.
19:01:19 <regXboi> marun: in that case, may I ask a q?
19:01:22 <marun> shoot
19:01:24 <banix> how about continuing now?
19:01:27 <mandeep> marun: We need to resolve this issue ASAP, we can not put this off by a few weeks
19:01:34 <marun> mandeep: completely agree.
19:01:48 <regXboi> if the patches are restructured to build up to EP/EPG first (as discussed earlier)
19:01:59 <banix> if we have the room and the audiance, shall we proceed?
19:01:59 <marun> mandeep: I'm raising issues, but I don't have to be involved.
19:02:04 <SumitNaiksatam> we are not getting kicked out yet
19:02:09 <regXboi> does this meet your concern by providing a natural point to implement the simple model?
19:02:11 <marun> mandeep: it's not my intention to hold anything up.
19:02:15 <SumitNaiksatam> so i think we can hang in here for a little longer
19:02:31 <regXboi> er simple implementation I mean?
19:02:43 <regXboi> sorry about the interleave :(
19:02:49 <SumitNaiksatam> regXboi: yes, so will discussed that we will get to EP and EPG at the earliest
19:02:51 <s3wong> so, I guess we should read marun 's email and armax 's response first?
19:02:53 <marun> regXboi: can the simple implementation be done without the complex model?
19:03:02 <SumitNaiksatam> regXboi: but again it need not be a suspense
19:03:11 <regXboi> marun: I have to go back and look, but I believe so, banix?
19:03:12 <SumitNaiksatam> regXboi: the PoC branch already has all of this
19:03:17 <mandeep> I was not in the summit, but I guess this is rehash of the original discussion on link based vs. contract based policy from early this year
19:03:27 <marun> yes
19:03:37 <banix> regXboi: yes it can
19:03:50 <mandeep> And that was discussed over at least 6 weeks in this forum before the current model was choosen
19:03:59 <SumitNaiksatam> ok let me level set here a little -
19:04:02 <regXboi> I think it also involves the process point of deviating from the BP, no?
19:04:25 <mandeep> The blueprint has the current model in it.
19:04:27 <SumitNaiksatam> lots of people are mistaking the optional parts of the model with what is required
19:04:33 <marun> Uh
19:04:42 <regXboi> marun: Uh to whom?
19:04:49 <marun> Sumit: Do these optional parts have corresponding implementation?
19:04:55 <SumitNaiksatam> without the optional parts it is indeed simple
19:05:00 <mandeep> marun: Yes
19:05:11 <SumitNaiksatam> marun: to your earlier point, this is a phased/iterative implementation
19:05:17 <marun> SumitNaiksatam: So would it be possible to propose _just_ the simple model as a starting point?
19:05:34 <marun> SumitNaiksatam: rather than trying to do it all at once?
19:05:37 <SumitNaiksatam> marun: that is what the current PoC implementation is
19:05:38 <mandeep> marun: We had a discussion on that as well
19:05:46 <marun> mandeep: and we're discussing it again.
19:06:10 <marun> SumitNaiksatam: I guess I find that surprising given the level of concern in the summit session at the complexity.
19:06:12 <mandeep> marun: And as long as people do not read those minutes, we will discuss it again
19:06:32 <SumitNaiksatam> marun: that is the problem, i believe people are misunderstanding
19:06:54 <SumitNaiksatam> marun: for instance you made claims about lack of simplicity, but i dont think you have read the docs or the code
19:07:02 <marun> SumitNaiksatam: So the complexity of the proposed implementation doesn't reflect the complexity of the logical model involved?
19:07:17 <marun> SumitNaiksatam: Maybe your definition of 'complexity' differ from mine.
19:07:28 <banix> So i think the question is if having an implementation based on the simpler model would be helpful as a first step
19:07:34 <banix> is that fair to say?
19:07:37 <SumitNaiksatam> marun: the team would hope that people make informed comments
19:07:40 <marun> banix: agreed.
19:07:50 <marun> SumitNaiksatam: That cuts both ways, I'm afraid.
19:08:08 <mandeep> SumitNaiksatam: What is robust is also fragile to a different set of constraints. Similarly what is simple is also complex for a different context.
19:08:22 <SumitNaiksatam> marun: well you cant accuse those implementing, to be not informed about the code they write, right?
19:08:34 <s3wong> banix: but the problem we already have some level of implementation of the model, so it is basically changing the code to "simpler" model?
19:08:36 <marun> mandeep: There is a need to socialize the concepts behind group policy to an audience of developers beyond this subteam.
19:08:38 <banix> just want to get an agreement as how we can move forward
19:09:01 <marun> mandeep: The way to do that is to implement something small and simple so that people can start to appreciate what you're trying to do.
19:09:28 <marun> mandeep: Front-ending the complexity is not a very good way to do this, imho.
19:09:31 <hemanthravi> i think the required subset of the contract model provides the simplicity of the other model
19:09:32 <SumitNaiksatam> marun: plenty of that has happened, it is not constructive if you choose to focus only on the people who choose to be not in the loop
19:09:55 <SumitNaiksatam> marun: by “that” i mean socialization
19:09:55 <LouisF> the "scoping" parts of the model do add complexity
19:09:58 <mandeep> marun: But if every change required a DB chnage and you deal with upgarde and back ward compatibility issues, you have just traded one complexity for anothert
19:10:06 <SumitNaiksatam> LouisF: scopes are optional
19:10:12 <marun> SumitNaiksatam: If you want to justify decisions made without consultation, that's certainly your choice.
19:10:12 <hemanthravi> and it's better to model all the resources, else it will be harder to add these in later
19:10:23 <SumitNaiksatam> marun: in fact quite the contrary
19:10:38 <banix> i am wondering if we leave out the optionals, moving to simpler model would be much of coding. I am underestimating the work? or shall we have a complete functional system wih the current model without the optionals. that is another way forward.
19:10:49 <hemanthravi> we are already seeing this wrt to lbaas and the adv services efforts
19:10:54 <marun> SumitNaiksatam: But I've yelled 'iterate in the open' so often it's getting boring, and I still don't think some of the folks in this room have heard me.
19:11:00 <SumitNaiksatam> marun: the effort and work has been no secret, so there is no need to justify anything
19:11:00 <mandeep> marun: Incrementally chnaging resources happens when there is no architecture to put things together to begin with
19:11:01 <s3wong> Agreed with hemanthravi here - the contract model with what we done in PoC so far is far from "complex" - it would be as "simple" as the link-based model
19:11:22 <LouisF> SumitNaiksatam: agree
19:11:24 <marun> mandeep: I call bs
19:11:31 <mandeep> And it has all been open and with team participation
19:11:39 <prasadv> marun: the iteration was done in open
19:11:44 <marun> no, it hasn't
19:11:51 <SumitNaiksatam> ok so let me level set again -
19:11:58 <mandeep> marun: I can call your feedback bs as well, but that is not the question here, is it?
19:12:03 <marun> iterate would be - simplest thing that could possibly work.
19:12:08 <marun> put it in gerrit and get it merged
19:12:12 <SumitNaiksatam> the spec captures the braoder model (including optional parts)
19:12:16 <marun> then start on the next piece
19:12:21 <s3wong> marun: IRC meeting, branch is public, link to branch on ML, what else can we do to make it more open?
19:12:24 <marun> and make sure it's architecturally coherent at every step
19:12:35 <SumitNaiksatam> the simplest part is what we are implementing now and is a subset of the model
19:12:59 <SumitNaiksatam> perhaps the optional pieces did not come out as clearly
19:12:59 <marun> s3wong: ^^ iterate in the open -> propose patches, merge them, repeat
19:13:20 <marun> s3wong: NOT iterate monolithically and then try to break things down
19:13:22 <mandeep> This was all done in open. It was all done iteratively
19:13:36 <marun> mandeep: ^^ uh, read what I just wrote
19:13:39 <banix> let’s focus on the way forward
19:13:42 <marun> mandeep: _merge_ patches and then iterate
19:13:45 <mandeep> The repo used was in the minutes.
19:13:56 <mandeep> The team was comfortable using github as that is faster
19:13:59 <hemanthravi> the current patch was needed to make it a functional block
19:14:01 <marun> mandeep: merge -> gerrit.  not external repo
19:14:09 <banix> what is the simplest yet meaningful set of patches we can have out for review
19:14:15 <mandeep> marun: Now were are discussing tools
19:14:24 <mandeep> marun: vs vs emacs?
19:14:30 <mandeep> marun: vi vs emacs?
19:14:36 <SumitNaiksatam> banix: i think we have have already discussed that
19:14:36 <marun> mandeep: nope.  I'm telling you what it takes to merge code to Neutron.  You're getting lost in the details .
19:14:37 <rkukura> marun: The PoC in github was intended as a learning exercise, and only lasted a couple weeks.
19:14:37 <banix> emacs is the best!
19:14:48 <rkukura> banix: +1
19:15:18 <mandeep> And I use both. YMMV
19:15:18 <marun> rkukura: fair enough.  so consider the poc as a prototype.  and then start iterating on doing it for real.
19:15:28 <marun> rkukura: (in gerrit)
19:15:33 <mandeep> marun: That is precisely what we are doing
19:15:38 <rkukura> marun: That is exactly what we are trying to do
19:15:51 <marun> mandeep: no, you're not.  you're breaking down the poc into chunks in the hopes of achieving a similar result
19:16:15 <marun> mandeep: but there is likely to be commentary that will require changes.  I'm just setting your expectations so it's not 'i'm done, merge'
19:16:31 <mandeep> marun: I was involved in PoC, I am doing the reviews. When I say, that is what I was doing, I know it as I was doing it
19:16:42 <marun> mandeep: I'm also pointing out that the review effort required is non-trivial, and Neutron has lots of other priorities.
19:16:43 <s3wong> manrun: OK - that's fair. We will revisit the PoC and start to iterate, instead of just breaking things in chunks
19:17:17 <SumitNaiksatam> s3wong: yes, that is what we are doing, hence the earlier items in the agenda today
19:17:17 <marun> s3wong: +1
19:17:41 <SumitNaiksatam> good so we have some level of agreement
19:17:42 <rkukura> I think we need to put some thought into how to build this thing up over a series of iterations in gerrit, not through continuing in the PoC codebase.
19:17:46 <s3wong> marun: but do keep in mind that there are workable code in the PoC also, and we will iterate those first
19:17:51 <marun> rkukura: +1
19:18:29 <banix> rkukura: +1
19:18:41 <SumitNaiksatam> everybody happy calling it a wrap for today? :-)
19:18:47 <s3wong> rkukura: yes, I think that is a good approach to get started
19:18:51 <banix> so it looks like we are getting somewhwere :)
19:18:51 <marun> SumitNaiksatam: +1
19:19:02 <s3wong> SumitNaiksatam: please :-)
19:19:05 <rkukura> We can continue to use the PoC codebase to prototype, but the real code gets developed in step-by-step in gerrit
19:19:05 <regXboi> Sumit: I'll get with banix if the time slot doesn't move
19:19:09 <mandeep> SumitNaiksatam: Good to see that we all agree on the process now
19:19:24 <SumitNaiksatam> regXboi: sure
19:19:31 <SumitNaiksatam> alrighty, thanks everyone
19:19:32 <marun> Your collective participation in the ml thread is appreciated.
19:19:44 <s3wong> marun: sure
19:19:47 <marun> And hopefully armax can help you organize any follow-up discussion.
19:20:04 <marun> As I said, I'll be off next week and I don't want to hold things up.
19:20:09 <mandeep> SumitNaiksatam will organize it (it was above)
19:20:18 <SumitNaiksatam> marun: so armax is your proxy? ;-)
19:20:52 <SumitNaiksatam> and again, thanks for all the work, this is indeed very good progress
19:20:54 <armax> I'll be more involved, I hope markmcclain1 can be too
19:20:56 <marun> From his reply on the ml I think he shares my concerns, so if you can satisfy him that should be fine.
19:21:07 <SumitNaiksatam> got it
19:21:11 <SumitNaiksatam> #endmeeting