18:01:59 #startmeeting networking_policy 18:02:00 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:04 The meeting name has been set to 'networking_policy' 18:02:19 #info agenda https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy 18:02:43 banix: Hi 18:02:54 firstly, thanks to everyone for the participation in the during the summit 18:03:18 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 hi 18:03:36 needless to say, it was very well received 18:04:02 uh 18:04:07 Great work by SumitNaiksatam rkukura hemanthravi prasadv ronak rudrarugge 18:04:12 yes, it was. banix, SumitNaiksatam, and me were mobbed after the presentation 18:04:32 s3wong: true 18:04:33 i think it is fair to say the public at large was very supportive of the direction 18:05:08 banix: Yes, I was viewing the presentation - very well done banix s3wong and SumitNaiksatam 18:05:09 that is the need for policy abstractions 18:05:10 I've sent an email to os-dev that paints a somewhat contradictory viewpoint. 18:05:20 okay to the first topic on the agenda 18:05:23 (and I should have added banix and s3wong to my last list ;-) 18:05:47 When did you send it marun 18:05:53 just now I'm afraid. 18:05:53 I did not see that 18:05:58 OK 18:06:00 ok lets follow the agenda items 18:06:05 marun: really? 18:06:18 so that we can get all items covered 18:06:29 I've added an item to the end of the agenda to discuss. 18:06:29 marun: we are mainly referring to the need for policy abstractions and not specifically a particular model and approach etc 18:06:33 so yes, let's move on. 18:06:38 marun: good 18:06:40 As it is just seconds before the meeting, we can not discuss to that I guess. 18:06:52 i will just go based on the order currently in the agenda 18:06:59 #topic Change of weekly meeting time 18:07:23 banix added that at my request 18:07:24 i thought we had good consensus on this time/day? 18:07:31 Yes 18:07:32 regXboi: ah ok 18:07:37 We finally got the meeting slot! 18:07:38 problem is that this overlaps with the ODL TSC which is 2 hours 18:07:46 conflicting with TCM at ODL 18:07:50 regXboi: actually we bounced off a few meetings times in the past 18:07:50 TSC 18:07:59 and several of the TSC members (myself included) are obligated to that 18:08:03 and can't participate in this 18:08:06 and it was difficult to find an open openstack channel 18:08:14 regXboi: We have tried quite a few slots and this is already the 3rd or 4th attempt 18:08:33 I would rather not chnage it again, if possible 18:08:39 SumitNaiksatam: perhaps pushing it earlier? I have a three hours slot between LBaaS and GP 18:08:55 mandeep: you are basically saying to TSC folks that are also working ODL GBP "go away" 18:09:27 but, I understand the problem with finding a good time 18:09:31 regXboi: Starting one hour later would work? 18:09:36 regXboi: we should definitely try to accomodate every one to the extent possible 18:09:41 starting one hour later would work 18:09:43 My morniong is also filled up, then I guess I will go away? 18:09:52 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 SumitNaiksatam: any chance we switch fwaas and this one? 18:09:56 one hour later will not work for ODL GBP folks 18:10:03 if others are ok with it that is 18:10:04 um 18:10:08 yes it will 18:10:23 prasadv: correct, I suggested earlier 18:10:40 s3wong: earlier works 18:10:46 is this a 60 minute or a longer irc? 18:11:02 banix: if we replace with fwaas, we will have two back-to-back heavy meetings (the former one is advanced services) 18:11:10 regXboi: this meeting is 60 min 18:11:15 if it's 60 minutes, there is a window between the end of this slot and the GBP ODL 18:11:23 er ODL GBP 18:11:26 SumitNaiksatam: yeah confused the dates 18:11:42 and to mandeep's point - I can't go earlier in the day 18:11:52 I'm blocked solid until when this slot ends 18:12:05 And I know that prasadv and hemanthravi travel after this call to the ODL call 18:12:12 ah 18:12:16 travel is an issue 18:12:22 we travel to the meeting most of the time 18:12:23 I'm remote to all of them... 18:12:27 regXboi: travel as in 10 minutes drive :-) 18:12:38 prasadv: you are very dedicated :) 18:12:45 longer than sub-minute irc->hangout/webex flip 18:12:54 okay, so lets bounce off some times off line 18:13:03 regXboi: any chance the ODL meeting can be moved? 18:13:05 sure... in the meantime, I can load up banix 18:13:14 SumitNaiksatam: no 18:13:18 regXboi: being optimistic :-) 18:13:18 it's a 2-hour slot 18:13:24 regXboi: np; will try to find a better time. 18:13:30 thanks all 18:13:47 #topic PoC status update 18:14:19 so while we achieved most of what we set out to do for the PoC, there were a few loose ends 18:15:09 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 rkukura s3wong you want to fill on that? 18:15:24 those loose ends being? 18:15:38 regXboi: on cue ^^^ :- 18:15:47 rkukura: want to go first? 18:15:49 * regXboi can play the straight person 18:15:57 sure 18:16:54 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 any work planned for redirect action? 18:17:43 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 LouisF: that's me. It will be next after ruukura :-) 18:18:16 LouisF: hi Louis, good to see you here 18:18:25 There are also some issues with allocating subnets from withint the RD’s supernet that need fixing. 18:18:29 good to meet at summit 18:19:18 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 rkukura: my turn? 18:19:50 rkukura: thanks 18:20:04 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 or is that later? 18:20:59 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 rkukura: thats a different agenda item 18:21:22 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 Second, to properly do redirect to a service (UUID), we need ServiceBase Object support, whose bp is already in gerrit 18:22:10 and coincidently, I (along with kanzhe) will be working on that 18:22:37 so to implement 'redirect' action properly on the mapping driver, that ServiceBase effort is a bit of a dependency 18:22:53 will ServiceBase be added to the POC branch? 18:23:26 LouisF: service base is intended to get the adavanced services framework going 18:23:38 LouisF: so it has applicability beyond group policy 18:23:39 LouisF: good question. In terms of checking in, the 'redirect' mapping driver part will obviously be after the ServiceBase work 18:23:52 LouisF: hopefully that will go in soon 18:23:55 in terms of PoC branch, I think porting it there for unit testing purpose makes sense 18:24:04 s3wong: is the redirect action specified on a rule or inside contract? 18:24:05 but won't be part of the check-in, of course 18:24:26 songole: redirect action, like all actions, is part of policy-rule 18:24:28 songole: rule 18:24:57 that's it for me 18:25:13 s3wong: ok thanks 18:25:28 any questions for rkukura or s3wong in terms of the above update? 18:25:32 s3wong: got it. thanks 18:26:04 $topic Gerrit reviews 18:26:10 what branch is ServiceBase work on? 18:26:28 SumitNaiksatam: use #topic 18:26:29 Policy Model: #link https://review.openstack.org/#/c/93853 18:26:39 LouisF: kanzhe and I will fork from Neutron to work on it - we are working on that now 18:26:46 Mapping Driver #link https://review.openstack.org/#/c/93935 18:27:13 #topic Gerrit reviews 18:27:18 rkukura: thanks :-) 18:27:26 above links dont change 18:27:36 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 so the first patch only has two resources now, and is the first in a series 18:28:26 the second patch is WIP, and is waiting for a few more patches to land on the model side 18:28:28 hmm nobody on channel yesterday 18:28:46 but the second patch should give a good idea about the mapping driver implementation 18:29:12 hopefully you all can review and provide constructive feedback 18:29:16 The 2nd will also be broken up into smaller patches when its dependencies are ready 18:29:32 LouisF: really? I was there yesterday, as were SumitNaiksatam, banix, kanzhe, rkukura, and many others... 18:29:34 rkukura: thanks 18:29:59 LouisF: yes, we had the meeting yesterday (was a full house) 18:30:19 any thoughts questions on the gerrit patches in review? 18:31:05 we are trying to breakdown the patches to smaller pieces so the review process is easier; is this being helpful? 18:31:16 I'll admit that I'm late to the party 18:31:48 banix: yeah good point 18:32:32 ok perhaps it is helpful, since no counter opinions 18:32:40 #topic Mapping driver 18:33:10 so rkukura wanted to spend a little bit of time on some the discussions around this topic 18:33:22 ok 18:33:23 rkukura: i believe you had a few items on the agenda 18:34:16 SumitNaiksatam: had to step away for sec, but do have questions on the reviews 18:34:28 #undo 18:34:28 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 Removing item from minutes: 18:34:37 rkukura: one sec 18:34:40 markmcclain1: go ahead 18:35:16 SumitNaiksatam: even with the smaller patches it is impossible to review because the code series doesn't actually work 18:35:43 markmcclain1: not quite sure, what you mean by code series doesnt actually work? 18:35:52 markmcclain1: Please explain. 18:36:02 SumitNaiksatam, markmcclain1: Unit tests should pass, right? 18:36:10 rkukura: yes they do 18:36:17 functionally it should work 18:36:28 UT should pass per chunk 18:36:37 markmcclain1: there is only patch in the series right now 18:36:38 And the entire policy can not be made to work with out all the policy objects being in place 18:36:48 markmcclain1: not sure what your expectation is 18:36:54 As requested by marun the patches are being split by resources 18:36:58 markmcclain1: an entire functional patch was posted 18:37:04 markmcclain1: you refused to review it 18:37:14 markmcclain1: becuause you wanted it broken down 18:37:15 SumitNaiksatam: I pointed out why it was a problem weeks ago. 18:37:17 markmcclain1: you got that 18:37:27 So the patches are now split 18:37:29 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 markmcclain1: there is only in the series 18:37:43 We’re breaking it up both by layers and by resources 18:37:45 markmcclain1: the others are coming 18:37:53 right the nice thing about breaking into patches is that code can be reviewed in chunks 18:38:01 but for functional testing the end result can be run 18:38:28 markmcclain1: sure, so you want that all patches be posted before you start reviewing? 18:38:36 And we do not expect you to approve the patches until they fit together in a function chunk 18:38:56 yes otherwise we're just looking at one tree at a time to figure out what the forrest looks like 18:39:19 That sounds nice in theory, but would basically force doing all the development outside the OpenStack gerrit environment, wouldn’t it? 18:39:35 rkukura: Quite the opposite 18:39:37 But the "tree" can be inspected for code issues and UTs etc 18:40:00 markmcclain1: yes, exactly for that reason there is also a PoC branch that be pulled and tested in entirety 18:40:27 SumitNaiksatam: exactly 18:40:51 gerrit will sequence the commits correctly 18:41:03 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 markmcclain1: absolutely 18:41:35 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 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 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 marun: I can not discuss that without having read it. 18:42:12 then go read it. 18:42:20 rkukura: thats a good point 18:42:21 I will. After this IRC 18:42:32 sure. then you won't be able to actually speak to my points. 18:42:43 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 I will respond on the ML 18:42:46 rkukura: you're right there is boilerplate 18:42:54 marun: yes, just read your email: #link http://lists.openstack.org/pipermail/openstack-dev/2014-May/035666.html 18:42:59 'the simplest thing that can possibly work' is generally the best thing. 18:43:04 marun: can we discuss one topic at a time.. first can we resolve checkin and resolution process 18:43:06 for anyone who actually read through the patch, it is indeed very boilerplate 18:43:08 especially when pushing new initiatives. 18:43:11 but the whole reason we started requiring implementations with APIs was because the lbaas API was so terrible 18:43:24 nobody really noticed until they tried to use it 18:43:27 Yes, I want to avoid religious discussions as well. 18:43:39 Let us focus on how to structure the checkin 18:44:07 okay, so let me stop this topic here 18:44:21 i think the expectation for some of the reviewers is that more patches land 18:44:21 mandeep: To be blunt, the question that needs to be answered is 'are we solving the right problem' 18:44:28 before they get a better feel 18:44:36 Rather than 'are we solving the problem right' 18:44:45 marun: We can discuss that independly of what the questions are on the current check-in 18:44:47 so lets do that (which I believe was the plan any way) 18:44:57 markmcclain1: does the address your concern as well? 18:45:04 marun: So that later if you undertsand that what we are doing is correct we would not have wasted time 18:45:29 marun mandeep: can i request you to hold your horses a bit 18:45:39 SumitNaiksatam: OK 18:45:43 there is a topic in the agena, we can take it up at that time 18:45:50 are there horses here? 18:45:54 :) 18:46:08 SumitNaiksatam: But I would prefer to get an answer on how to strcutre the patches 18:46:28 mandeep: i think we have agreement that patches are structured in the right way 18:46:29 SumitNaiksatam: Do we have agreement on what would be acceptable 18:46:38 mandeep: just that more patches need to land 18:46:38 SumitNaiksatam: Cool 18:46:50 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 SumitNaiksatam: In that case, I am Ok to move on to the next phase 18:47:34 markmcclain1: you can either have smaller chunks, and but more patches, or bigger chunks with less patches :-) 18:47:49 markmcclain1: i believe you wanted smaller chunks, in a series 18:47:55 I want both :) 18:47:56 markmcclain1: Policy is a big item, you can not just solve a part of it 18:48:15 markmcclain1: well you will need to teach us to bend the laws of physics then 18:48:16 mandeep: no comment 18:48:17 mandeep: fully aware.. just making sure that we have good items to test 18:48:30 markmcclain1: Either that, or as a community we are not going to sign up to solving big problems 18:48:31 the lbaas experience from 2 yrs ago still haunts 18:48:47 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 mandeep: there are more than 1 ways to skin a cat 18:49:26 rkukura: that does seem like something that could prove workable 18:49:37 ie a series that gets us to Endpoints/Groups 18:49:56 marun: I challenge you to show ONE real life policy based service deployment system that is "small" 18:49:56 markmcclain1: ok we should be able to endpoints and groups in less than 20 patches :-) 18:50:07 SumitNaiksatam: cool 18:50:10 mandeep: I challenge you to find a single workable system that wasn't developed incrementally. 18:50:22 (in open source) 18:50:39 marun: This has been developed incrementally - week after week - you joined the party late 18:50:49 mandeep: incrementally outside of oversight 18:51:00 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 marun: There was oversight 18:51:07 mandeep: not from the wider neutron community 18:51:10 so we wil get to taht 18:51:15 markmcclain1: sound okay? 18:51:18 marun: the whole team worked on an open repo tigether 18:51:34 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 SumitNaiksatam: from a review perspective yes 18:51:36 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 marun: With oversignt from multiple neutron cores 18:51:58 ok moving back to the earlier topic 18:52:03 #topic Mapping driver 18:52:05 nothing that can't be remedied, but pretending it's not a problem seems pretty silly 18:52:07 marun: You know better than other cores, obviously 18:52:14 mandeep: really? 18:52:16 SumitNaiksatam: thanks for indulging my review process questions 18:52:20 the PoC is just that, trying to prove some concepts before submitting code for formal review 18:52:37 markmcclain1: Thanks for the clarification 18:52:59 markmcclain1: always 18:53:47 back to the current topic… 18:53:53 rkukura: please 18:54:03 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 rkukura: maybe a short summary, so that we can to get the other items as well 18:54:42 So I’m looking into putting that into a separate driver that runs before the mapping driver. 18:55:21 rkukura: i like that idea 18:55:35 rkukura: +1 18:55:41 so um hold 18:55:45 rkukura: will this be in the PoC branch? 18:55:46 Will also make a meaningful chunk for review ;) 18:56:00 I'm still a little unclear how bridge and router domains come into this discussion? 18:56:01 rkukura: :-) 18:56:28 regXboi: that was the next topic on the agenda 18:56:39 #topic Resource name changes 18:56:39 * regXboi plays straight man again 18:56:42 ok I can wait :) 18:56:58 regXboi: it seems that BD and RD names are causing a lot of confusion 18:57:12 and are being interpreted for what they are not 18:57:23 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 SumitNaiksatam: Propose change names to L3-policy-context and L2-policy-context 18:57:53 mandeep: +1 18:58:02 mandeep: +1 18:58:07 mandeep: +1 18:58:08 mandeep: yeah something like that will be good 18:58:20 Some risk of confusion around the work “context” since its used in the driver API (based on ML2’s similar pattern) 18:58:34 lets think a little more on this (since these are just meant to hold context attributes) 18:58:42 ok moving on 18:58:48 But L?PolicyContext is fine with me 18:58:54 want to make sure give time for marun’s agenda item 18:59:02 #topic Summit session post-mortem 18:59:10 2 minutes? :-) 18:59:21 we can go a little over unless we get kicked out 18:59:22 armax: has suggested on the ml thread to schedule an ad-hoc meeting to discuss 18:59:29 (but hopefully not a neverending debate) 18:59:31 s3wong: I can sacrifice my luch to hear this 18:59:41 yeah just a minute is not gonna cut it 18:59:41 :) 18:59:44 And that would give folks a chance to read it. 18:59:46 I'm in for the long haul 19:00:09 sounds reasonable 19:00:13 So, no need to extend, we can schedule something later. 19:00:31 SumitNaiksatam: Will you be scheduling this ad-hoc meeting? 19:00:44 sure, 19:00:47 and more to the point: "how" will the meeting get scheduled? 19:00:50 we can have another meeting :-) 19:00:51 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 marun: in that case, may I ask a q? 19:01:22 shoot 19:01:24 how about continuing now? 19:01:27 marun: We need to resolve this issue ASAP, we can not put this off by a few weeks 19:01:34 mandeep: completely agree. 19:01:48 if the patches are restructured to build up to EP/EPG first (as discussed earlier) 19:01:59 if we have the room and the audiance, shall we proceed? 19:01:59 mandeep: I'm raising issues, but I don't have to be involved. 19:02:04 we are not getting kicked out yet 19:02:09 does this meet your concern by providing a natural point to implement the simple model? 19:02:11 mandeep: it's not my intention to hold anything up. 19:02:15 so i think we can hang in here for a little longer 19:02:31 er simple implementation I mean? 19:02:43 sorry about the interleave :( 19:02:49 regXboi: yes, so will discussed that we will get to EP and EPG at the earliest 19:02:51 so, I guess we should read marun 's email and armax 's response first? 19:02:53 regXboi: can the simple implementation be done without the complex model? 19:03:02 regXboi: but again it need not be a suspense 19:03:11 marun: I have to go back and look, but I believe so, banix? 19:03:12 regXboi: the PoC branch already has all of this 19:03:17 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 yes 19:03:37 regXboi: yes it can 19:03:50 And that was discussed over at least 6 weeks in this forum before the current model was choosen 19:03:59 ok let me level set here a little - 19:04:02 I think it also involves the process point of deviating from the BP, no? 19:04:25 The blueprint has the current model in it. 19:04:27 lots of people are mistaking the optional parts of the model with what is required 19:04:33 Uh 19:04:42 marun: Uh to whom? 19:04:49 Sumit: Do these optional parts have corresponding implementation? 19:04:55 without the optional parts it is indeed simple 19:05:00 marun: Yes 19:05:11 marun: to your earlier point, this is a phased/iterative implementation 19:05:17 SumitNaiksatam: So would it be possible to propose _just_ the simple model as a starting point? 19:05:34 SumitNaiksatam: rather than trying to do it all at once? 19:05:37 marun: that is what the current PoC implementation is 19:05:38 marun: We had a discussion on that as well 19:05:46 mandeep: and we're discussing it again. 19:06:10 SumitNaiksatam: I guess I find that surprising given the level of concern in the summit session at the complexity. 19:06:12 marun: And as long as people do not read those minutes, we will discuss it again 19:06:32 marun: that is the problem, i believe people are misunderstanding 19:06:54 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 SumitNaiksatam: So the complexity of the proposed implementation doesn't reflect the complexity of the logical model involved? 19:07:17 SumitNaiksatam: Maybe your definition of 'complexity' differ from mine. 19:07:28 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 is that fair to say? 19:07:37 marun: the team would hope that people make informed comments 19:07:40 banix: agreed. 19:07:50 SumitNaiksatam: That cuts both ways, I'm afraid. 19:08:08 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 marun: well you cant accuse those implementing, to be not informed about the code they write, right? 19:08:34 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 mandeep: There is a need to socialize the concepts behind group policy to an audience of developers beyond this subteam. 19:08:38 just want to get an agreement as how we can move forward 19:09:01 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 mandeep: Front-ending the complexity is not a very good way to do this, imho. 19:09:31 i think the required subset of the contract model provides the simplicity of the other model 19:09:32 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 marun: by “that” i mean socialization 19:09:55 the "scoping" parts of the model do add complexity 19:09:58 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 LouisF: scopes are optional 19:10:12 SumitNaiksatam: If you want to justify decisions made without consultation, that's certainly your choice. 19:10:12 and it's better to model all the resources, else it will be harder to add these in later 19:10:23 marun: in fact quite the contrary 19:10:38 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 we are already seeing this wrt to lbaas and the adv services efforts 19:10:54 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 marun: the effort and work has been no secret, so there is no need to justify anything 19:11:00 marun: Incrementally chnaging resources happens when there is no architecture to put things together to begin with 19:11:01 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 SumitNaiksatam: agree 19:11:24 mandeep: I call bs 19:11:31 And it has all been open and with team participation 19:11:39 marun: the iteration was done in open 19:11:44 no, it hasn't 19:11:51 ok so let me level set again - 19:11:58 marun: I can call your feedback bs as well, but that is not the question here, is it? 19:12:03