18:01:17 #startmeeting networking_policy 18:01:18 Meeting started Thu Sep 4 18:01:17 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:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:21 The meeting name has been set to 'networking_policy' 18:01:33 #info agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy 18:01:34 <6A4AAKDJG> Am I showing up as 6A4AAKDJG ? Its rkukura, actually. 18:02:03 6A4AAKDJG: wow! how did you manage that? ;-) 18:02:23 <6A4AAKDJG> SumitNaiksatam: No idea! I’m going to disconnect and reconnect. 18:02:32 wanted to do a quick status update on the patches which are in gerrit 18:02:51 #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches 18:02:58 #topic Neutron patches 18:03:19 s3wong had been working on the SG mapping piece 18:03:20 hi again 18:03:36 rkukura: no we recognize you, welcome back 18:03:46 s3wong: any update from last week? 18:03:54 identity crisis ;) 18:04:41 i think s3wong is wrapping up a few things on the GPM-RMD-SG patch 18:04:55 meanwhile, the series had gotten messed up because of some rebases 18:05:03 yesterday night we fixed that 18:05:19 so now everything should be back where we left off 18:05:38 and is rebased with the latest 18:05:45 nice! 18:06:02 SumitNaiksatam: Thanks! I’ll sanity check my patches when I get a chance. 18:06:10 rkukura: yes definitely 18:06:17 ivar-lazzaro: thanks for pointing it out 18:06:32 the last patch in the series is #link https://review.openstack.org/#/c/113775 18:07:07 so s3wong mentioned that there was something wrong with the UTs which he did not catch earlier 18:07:13 hence its failing 18:07:24 i did not have a chance to look in the details 18:07:50 #topic Client/CLI 18:07:57 songole: there? 18:08:02 Hi 18:08:23 songole: any updates, or the current set of patches is stable? 18:08:30 No updates to CLI. 18:08:43 Naming changes need to be done. 18:08:44 songole: so its rebased and everything? 18:08:59 songole: naming changes have not happened at the backend 18:09:07 Need to rebase. 18:09:09 ok 18:09:12 songole: so you wont be able to do it anyway :-) 18:09:29 ok 18:09:30 songole: okay, it will be great if you can rebase when you get a chance 18:09:43 Anyone had a chance to test CLI? 18:10:15 songole: plan to give that a shot, but i thought horizon was already leveraging the client 18:10:25 songole: I did two weeks back 18:10:30 songole: so some level of automatic validation already done 18:10:33 rms_13: yes, thanks 18:10:35 and it looked ok 18:10:43 ok. thanks 18:10:48 sorry, in late 18:10:51 songole: thanks for the update 18:11:01 s3wong: no worries, i provided update on your behalf 18:11:02 Didnt get to test all of it but whatever is there in horizon so far was working fine after rebase 18:11:07 s3wong: but feel free to chime in 18:11:27 rms_13: thanks, will come to the Horizon update next as well 18:11:36 yes, as SumitNaiksatam said, I believe all the test failures indicates that the unit test is probably broken, so I will look into that 18:11:49 s3wong: yes, no worries 18:12:08 s3wong: thanks 18:12:24 songole: thanks as well for the update on CLI/client 18:12:35 #topic Horizon 18:13:03 rms_13: go ahead 18:13:09 any updates? 18:13:18 I need to rebase my patch 18:13:26 rms_13: ah, was just saying 18:13:36 Somebody needs to review the baseline changes 18:13:39 rms_13: but other than that, to what extent is the UI functional? 18:13:58 So that grunt work can start as part of add-on patches 18:14:41 Policy-Group, Policy-rules, Contract, Action (CRUD) 18:15:19 Update is not part of the current patch but have it ready in private patch. Once that looks good to all, as I said earlier, other resources can be added in similar fashion 18:15:44 rms_13: was abishek helping you with the reviews? 18:15:54 So far no updates from him 18:16:23 rms_13: ok 18:16:26 Nati also wanted to take a look...no updates from him either 18:16:47 rms_13: so you are looking for input from a code review perspective, or feedback on the UI organization? 18:17:32 rms_13: i am guessing its both 18:17:33 Both together...basically I think the organization is correct. But than; I dont want to code another 3000 lines and get -2 saying the org is wrong :) 18:17:44 rms_13: true 18:18:26 First major validation/approval I need is that Group Policy tab can seat in main panel rather than network's panel (as we demoed at Atlanta) 18:18:29 rms_13: that said i think it will be difficult to get reviewer attention late in the Juno cycle 18:19:06 rms_13: okay, valid concerns 18:19:07 I understand. Have some idea about that. Will share it on the email for more discussion 18:19:53 rms_13: yeah, i was going to suggest that if you can summarize your concerns and the items that you are soliciting feedback on, that will be great 18:20:05 rms_13: we can then try to close on those online/offline 18:20:09 sure will do... 18:20:23 rms_13: great, thanks! 18:20:31 #topic Heat 18:20:36 susaant: hi there 18:20:56 susaant: any updates at your end? 18:21:02 I dont have any updates on heat patches 18:21:29 susaant: okay, the patch seems to have failed some UTs 18:21:44 susaant: is that a minor issue? 18:22:01 yes. Thats because the GBP neutron resources are not present.. 18:22:08 susaant: ah got it 18:22:24 susaant: so in a private devstack setup, this works 18:22:35 private -> local 18:22:36 hmm... obviously we bored banix enough for him to leave :-) 18:22:36 that is correct. 18:22:59 susaant: okay great thanks 18:23:40 #topic GBP repo/home discussion 18:23:55 #link http://lists.openstack.org/pipermail/openstack-dev/2014-September/044834.html 18:24:21 the above email was sent on behalf of the team 18:24:40 and captures some of the options that were or have been suggested 18:24:53 any thoughts? 18:25:05 SumitNaiksatam: thanks for the email. 18:25:32 SumitNaiksatam: the Neutron feature idea never picked up any momentum, are we still considering it? 18:26:03 s3wong: Do you mean the “feature branch” idea? 18:26:16 I was reading on the incubator program wiki (https://wiki.openstack.org/wiki/Network/Incubator) 18:26:18 s3wong: i am not aware what the current status on that is 18:26:18 rkukura: yes (sorry for mssing a word) 18:26:19 s3wong: Or the preview subtree idea, which isn’t even listed. 18:26:30 rkukura: feature branch 18:26:50 I spoke with our PTL, mestery, yesterday, and he indicated that feature branches are being planned 18:27:06 rkukura: oh, really? 18:27:13 That’s what I said 18:27:44 rkukura: when would the planned branch happen 18:27:56 rkukura: in that case, it is only applicable for Neutron features that can be packaged and lived completely isolated from Neutron 18:28:16 would it have same non dterministic behaviour as incubaotr 18:28:28 rkukura: which GBP so far is 18:28:30 s3wong: what sort of features? 18:28:49 LouisF: something like GBP, I believe 18:29:07 To me, advantage of the feature branch option are: 1) clear path into neutron on graduation, 2) no loss of git history on graduation 18:29:45 s3wong: is there precedent for feature branches? 18:30:02 What is the procedure on code review on feature branch? Any decision on that yet? 18:30:09 LouisF: as rkukura said above, it is an idea from mestery at this point 18:30:36 Concerns I’ve heard raised are: 1) no CI for existing non-master branches (stable branches), and 2) not clear if existing packaging for stable branches is applicable/adequate for feature branches 18:31:27 rkukura: until “graduation” would the feature live in isolation (that is the feature branch, if packaged, has to be packaged all by itself, essentially a fork)? 18:31:56 rkukura: wont (1) and (2) be the same for incubation or stackforge? 18:32:04 SumitNaiksatam: I think that depends if the branch is purely additive or modifies code from master/stable branches 18:32:08 s3wong: rkukura so feature branches are a completely new idea? 18:32:56 LouisF: yes, it doesn't exist today 18:33:02 rkukura: true, so for example if two features are developed in paralled features branches, then you can essentially only deploy one of them from a package, right? 18:34:00 I’m only familiar with Red Hat’s packaging process (worked there previously), but I see no reason any number of purely additive feature branches could not be packaged to depend on the normal neutron packages. 18:34:49 prasadv: to your question, #link http://ci.openstack.org/stackforge.html states that stackforge projects have jenkins continuous integration support 18:35:33 In all these approaches, I am very concern about the merge into neutron (so called graduation time). There possibly would be huge patches needed to be reviewed and regressed (one for every feature) and that will take lot of review time of cores. Any clear path defined to handle those? 18:35:41 SumitNaiksatam: my take is that the way people have been discussing incubator, it sounds like they want it to be separate package also - though perhaps everything in incubator is one package, instead of say a GBP package and a LBaaSv2 package 18:36:07 rkukura: okay, but probably related features are likely to have some overlap 18:36:22 rms_13: I think either the incubator or feature branch option involves core reviews on the way in, so re-review on graduation would be minimal 18:37:13 rkukura: thats a good hope. But typically everybody is excited to see a new kid and wants to give blessings or two :) 18:37:38 rkukura: in that case, what is the major difference between incubator and feature branches - that each feature will occupy a branch (and separate packaging)? 18:38:07 Unless there is a stringent requirement that re-review MUST be minimal (or by those cores only involved from incubation phase); I am not too confident that that would happen. 18:38:27 s3wong: Main difference is that graduation of a feature branch is just a merge, preserving git histrory (I think) 18:38:30 All I want to suggest is that we should push hard for strict rules on that front. Nothing else 18:39:13 rms_13: Agreed. I can definitely see another "-2: too large" or "-2: lack consensus" type situation 18:39:28 s3wong: +100 18:40:01 s3wong, rms_13: The graduation hurdle is definitely a risk with any of the options, but only the feature branch option preserves history. 18:40:27 rkukura: in that sense, stackforge is not an option 18:40:36 so it seems like the only difference between the feature branch and the incubator is with the ease in preservation of git history 18:41:03 I think the hurdle to get into neutron is signfiicantly higher with the stackforge option than any of the others. 18:41:27 But there are no guarantees with any of them, meaning we could end up as a separate project. 18:41:38 the process and policies would be similar for both (i am just summarizing based on the information presented above, i havent seen a wiki yet) 18:41:42 rkukura: Agree. If and only if the merging guidelines is clearly defined (including review scheme) 18:42:00 rms_13: i dont think anyone can gaurantee a merge :-) 18:42:11 rms_13: it is an inherently subjective area 18:42:50 SumitNaiksatam: Than better do it on stackforge 18:42:51 the principle of loose consensus allows for negative votes at any time in the liefcycle 18:43:00 The one thing I think there is agreement on in all of these discussions is that forking into a separate repo is way easier than merging into an existing one. 18:43:01 rkukura: SumitNaiksatam: if the main goal is to allow users to use it, is GBP being part of Neutron really that important? 18:43:48 s3wong: that is good point, and Octavia, I believe has taken that view 18:44:11 s3wong: they want to iterate faster, and provide something useable and put it into people’s hands 18:44:28 s3wong: If we see tight coupling, as in living in the same process as neutorn, intercepting neutron requests, and ML2 mechanism drivers working closely with policy drivers, being part of neutron seems essential. 18:44:44 i also think that the approaches we are discussing are perhaps not mutually exclusive 18:45:05 s3wong, SumitNaiksatam: Good points. Lets say we take octavia like route. How does interaction with other openstack system works in that case? 18:45:22 But as I understand it, octavia is a separate thing, basically a reference implementation of a load balancer datapath. 18:45:58 rms_13: in the same way, taht for example nova interacts with neutron 18:46:41 To me the neutron/octavia interface isn’t that different than the neutron/ODL interface or even the nova/KVM interface. 18:47:14 rkukura: i agree, octavia is not in the same zip code as a feature as GBP is 18:47:55 rkukura: i brought up the analogy from a process perspective (in terms of being able to iterate faster and deliver to something usable) in response to s3wong’s point 18:47:59 We could certainly decide that GBP should be a separate project with its own server than uses neutron via python-neutronclient, and go in that direction 18:48:07 rkukura: people in Octavia project (and LBaaSv2 project) has plan to spin out the entire LBaaS from Neutron 18:48:26 rkukura: and what is missing is a clean interface for how LBaaS uses Neutron 18:48:47 s3wong: and we tried hard to fix that :-) 18:49:03 s3wong: Or how neutron uses LBaaS (if neutron is policy-based and controls load balancing via actions) 18:49:04 rkukura: thinking of NOT having GBP in Neutron can also get us to think about what external interfaces does Neutron lack 18:50:29 s3wong: +1 18:50:49 s3wong: That is a good point 18:51:11 To me, separate projects implies separate servers in separate processes with separate REST APIs. Is that others’ understanding as well? 18:51:44 rkukura: yes 18:52:09 rkukura: you are asking the GBP context? 18:52:24 rkukura: or a general question? 18:52:40 rkukura: yes 18:53:02 SumitNaiksatam: general, but with implications for GBP if we were to decide graduation into neutron was no longer a goal. 18:53:21 SumitNaiksatam: would stackforge imply also we could get GBP into J timeframe. Seems like the other options might not make it within J timeframe isnt it 18:53:23 rkukura: okay 18:54:39 I would think setting up a new project with its own WSGI/REST framework would take significant time, and not be anything but a WIP at Juno release. 18:54:42 prasadv: well, stackforge will take at least two cycles to go from incubation to mainline 18:54:45 prasadv: i havent worked through a stackforge myself, there is an application process involved (i believe its just a gerrit review) 18:55:19 prasadv: but then again, we aren't making it to J timeframe anyway 18:55:21 Or are we talking about a service plugin in stackforge, that is not a separate project/server/process from neutron? 18:55:44 rkukura: yes, i think we need to work through those options better 18:56:13 My view is that we could merge our stuff to a fearture branch off of Juno-3 or Juno-RC1, then rebase this to Juno at about the time Juno ships. 18:56:16 s3wong: if i understood prasadv correctly, he was not asking about incubatiio, he was just asking when can you get a package ready? :-) 18:56:33 *incubation and graduation 18:56:56 So is “stackforge” really two different options: service plugin vs. stand-alone service? 18:57:34 rkukura: perhaps 18:57:58 rkukura: so lets if lbaas were to spin out today 18:58:17 is lbaasv2 being implemented as a service plugin in stackforge? 18:58:17 rkukura: i think they would have to consider the same choice, right? 18:58:34 songole: currently lbaasv2 is not in stackforge 18:58:47 songole: it was proposed in neutron, but its in the same boat as GBP 18:58:55 songole: they are evaluating the options 18:59:03 ok 18:59:17 songole: it isn't in stackforge yet 18:59:25 SumitNaiksatam: I agree for the LBaSSv2 REST API, but octavia as a datapath is inherently a separate process (or VM?) isn’t it? 18:59:43 songole: what is in stackforge is Octavia, which is more of a driver/reference implemenation for lbaas 18:59:57 rkukura: true 19:00:14 rkukura: but i was saying in the context of the discussion in the ML 19:00:34 rkukura: wherein people are accepting that the different services will be spun out into separate projects 19:00:44 rkukura: eventually 19:00:46 SumitNaiksatam: yep, only Octavia is in stackforge, but Octavia follows LBaaSv2, and therefore it is a bit hairy 19:01:00 s3wong: yes thanks 19:01:07 okay folks we have hit the hour 19:01:10 SumitNaiksatam: so there is a LBaaS email thread that is talking about whether they should pull LBaaSv2 off there also 19:01:14 SumitNaiksatam: Do you mean as service plugins in separate projects, or new as new services? 19:01:28 was only hoping to seed the discussion 19:01:46 SumitNaiksatam: yeah, no way to finalize on our plan during this meeting :-) 19:01:58 rkukura: i am not sure, but what i meant was that they will be faced with the same choice or dilema that we have are discussing now 19:02:07 My view is that neutron-server (and the neutron project) should be the API and orchestration layer, and not include any datapaths. 19:02:14 s3wong: yes there is an email thread to that effect 19:02:41 rkukura: true, but neutron has also has a narrow defintion of what that API should be 19:02:59 rkukura: so that opens up bigger questions 19:03:04 alrighty folks 19:03:08 lets wrap it here 19:03:09 SumitNaiksatam: seems like we need to decide soon on the options soon right? 19:03:16 and continue on the ML 19:03:18 prasadv: yes sure 19:03:32 prasadv: lets leverage the ML as well 19:03:35 prasadv: yes, but I believe any option would at least take two cycles 19:03:43 It sounds to me like mestery and markmcclain are trying to nail down feature branch details like CI and packaging as we speak 19:03:52 s3wong: for graduation right? 19:04:00 it will be good to let the community know where the GBP is leaning (or what the technical choices and pros/cons are) 19:04:01 incubator as defined by markmcclain takes two cycles to graduate 19:04:06 prasadv: yes 19:04:34 s3wong: ok. But which option will get us in front of customers faster 19:04:49 I think that should be important 19:05:00 prasadv: point well taken 19:05:06 on that note, lets end for today 19:05:10 #endmeeting