18:01:17 <SumitNaiksatam> #startmeeting networking_policy
18:01:18 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:21 <openstack> The meeting name has been set to 'networking_policy'
18:01:33 <SumitNaiksatam> #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 <SumitNaiksatam> 6A4AAKDJG: wow! how did you manage that? ;-)
18:02:23 <6A4AAKDJG> SumitNaiksatam: No idea! I’m going to disconnect and reconnect.
18:02:32 <SumitNaiksatam> wanted to do a quick status update on the patches which are in gerrit
18:02:51 <SumitNaiksatam> #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches
18:02:58 <SumitNaiksatam> #topic Neutron patches
18:03:19 <SumitNaiksatam> s3wong had been working on the SG mapping piece
18:03:20 <rkukura> hi again
18:03:36 <SumitNaiksatam> rkukura: no we recognize you, welcome back
18:03:46 <SumitNaiksatam> s3wong: any update from last week?
18:03:54 <rkukura> identity crisis ;)
18:04:41 <SumitNaiksatam> i think s3wong is wrapping up a few things on the GPM-RMD-SG patch
18:04:55 <SumitNaiksatam> meanwhile, the series had gotten messed up because of some rebases
18:05:03 <SumitNaiksatam> yesterday night we fixed that
18:05:19 <SumitNaiksatam> so now everything should be back where we left off
18:05:38 <SumitNaiksatam> and is rebased with the latest
18:05:45 <ivar-lazzaro> nice!
18:06:02 <rkukura> SumitNaiksatam: Thanks! I’ll sanity check my patches when I get a chance.
18:06:10 <SumitNaiksatam> rkukura: yes definitely
18:06:17 <SumitNaiksatam> ivar-lazzaro: thanks for pointing it out
18:06:32 <SumitNaiksatam> the last patch in the series is #link https://review.openstack.org/#/c/113775
18:07:07 <SumitNaiksatam> so s3wong mentioned that there was something wrong with the UTs which he did not catch earlier
18:07:13 <SumitNaiksatam> hence its failing
18:07:24 <SumitNaiksatam> i did not have a chance to look in the details
18:07:50 <SumitNaiksatam> #topic Client/CLI
18:07:57 <SumitNaiksatam> songole: there?
18:08:02 <songole> Hi
18:08:23 <SumitNaiksatam> songole: any updates, or the current set of patches is stable?
18:08:30 <songole> No updates to CLI.
18:08:43 <songole> Naming changes need to be done.
18:08:44 <SumitNaiksatam> songole: so its rebased and everything?
18:08:59 <SumitNaiksatam> songole: naming changes have not happened at the backend
18:09:07 <songole> Need to rebase.
18:09:09 <songole> ok
18:09:12 <SumitNaiksatam> songole: so you wont be able to do it anyway :-)
18:09:29 <songole> ok
18:09:30 <SumitNaiksatam> songole: okay, it will be great if you can rebase when you get a chance
18:09:43 <songole> Anyone had a chance to test CLI?
18:10:15 <SumitNaiksatam> songole: plan to give that a shot, but i thought horizon was already leveraging the client
18:10:25 <rms_13> songole: I did two weeks back
18:10:30 <SumitNaiksatam> songole: so some level of automatic validation already done
18:10:33 <SumitNaiksatam> rms_13: yes, thanks
18:10:35 <rms_13> and it looked ok
18:10:43 <songole> ok. thanks
18:10:48 <s3wong> sorry, in late
18:10:51 <SumitNaiksatam> songole: thanks for the update
18:11:01 <SumitNaiksatam> s3wong: no worries, i provided update on your behalf
18:11:02 <rms_13> Didnt get to test all of it but whatever is there in horizon so far was working fine after rebase
18:11:07 <SumitNaiksatam> s3wong: but feel free to chime in
18:11:27 <SumitNaiksatam> rms_13: thanks, will come to the Horizon update next as well
18:11:36 <s3wong> 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 <SumitNaiksatam> s3wong: yes, no worries
18:12:08 <SumitNaiksatam> s3wong: thanks
18:12:24 <SumitNaiksatam> songole: thanks as well for the update on CLI/client
18:12:35 <SumitNaiksatam> #topic Horizon
18:13:03 <SumitNaiksatam> rms_13: go ahead
18:13:09 <SumitNaiksatam> any updates?
18:13:18 <rms_13> I need to rebase my patch
18:13:26 <SumitNaiksatam> rms_13: ah, was just saying
18:13:36 <rms_13> Somebody needs to review the baseline changes
18:13:39 <SumitNaiksatam> rms_13: but other than that, to what extent is the UI functional?
18:13:58 <rms_13> So that grunt work can start as part of add-on patches
18:14:41 <rms_13> Policy-Group, Policy-rules, Contract, Action (CRUD)
18:15:19 <rms_13> 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 <SumitNaiksatam> rms_13: was abishek helping you with the reviews?
18:15:54 <rms_13> So far no updates from him
18:16:23 <SumitNaiksatam> rms_13: ok
18:16:26 <rms_13> Nati also wanted to take a look...no updates from him either
18:16:47 <SumitNaiksatam> rms_13: so you are looking for input from a code review perspective, or feedback on the UI organization?
18:17:32 <SumitNaiksatam> rms_13: i am guessing its both
18:17:33 <rms_13> 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 <SumitNaiksatam> rms_13: true
18:18:26 <rms_13> 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 <SumitNaiksatam> rms_13: that said i think it will be difficult to get reviewer attention late in the Juno cycle
18:19:06 <SumitNaiksatam> rms_13: okay, valid concerns
18:19:07 <rms_13> I understand. Have some idea about that. Will share it on the email for more discussion
18:19:53 <SumitNaiksatam> 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 <SumitNaiksatam> rms_13: we can then try to close on those online/offline
18:20:09 <rms_13> sure will do...
18:20:23 <SumitNaiksatam> rms_13: great, thanks!
18:20:31 <SumitNaiksatam> #topic Heat
18:20:36 <SumitNaiksatam> susaant: hi there
18:20:56 <SumitNaiksatam> susaant: any updates at your end?
18:21:02 <susaant> I dont have any updates on heat patches
18:21:29 <SumitNaiksatam> susaant: okay, the patch seems to have failed some UTs
18:21:44 <SumitNaiksatam> susaant: is that a minor issue?
18:22:01 <susaant> yes. Thats because the GBP neutron resources are not present..
18:22:08 <SumitNaiksatam> susaant: ah got it
18:22:24 <SumitNaiksatam> susaant: so in a private devstack setup, this works
18:22:35 <SumitNaiksatam> private -> local
18:22:36 <s3wong> hmm... obviously we bored banix enough for him to leave :-)
18:22:36 <susaant> that is correct.
18:22:59 <SumitNaiksatam> susaant: okay great thanks
18:23:40 <SumitNaiksatam> #topic GBP repo/home discussion
18:23:55 <SumitNaiksatam> #link http://lists.openstack.org/pipermail/openstack-dev/2014-September/044834.html
18:24:21 <SumitNaiksatam> the above email was sent on behalf of the team
18:24:40 <SumitNaiksatam> and captures some of the options that were or have been suggested
18:24:53 <SumitNaiksatam> any thoughts?
18:25:05 <prasadv> SumitNaiksatam: thanks for the email.
18:25:32 <s3wong> SumitNaiksatam: the Neutron feature idea never picked up any momentum, are we still considering it?
18:26:03 <rkukura> s3wong: Do you mean the “feature branch” idea?
18:26:16 <rms_13> I was reading on the incubator program wiki (https://wiki.openstack.org/wiki/Network/Incubator)
18:26:18 <SumitNaiksatam> s3wong: i am not aware what the current status on that is
18:26:18 <s3wong> rkukura: yes (sorry for mssing a word)
18:26:19 <rkukura> s3wong: Or the preview subtree idea, which isn’t even listed.
18:26:30 <s3wong> rkukura: feature branch
18:26:50 <rkukura> I spoke with our PTL, mestery, yesterday, and he indicated that feature branches are being planned
18:27:06 <s3wong> rkukura: oh, really?
18:27:13 <rkukura> That’s what I said
18:27:44 <prasadv> rkukura: when would the planned branch happen
18:27:56 <s3wong> rkukura: in that case, it is only applicable for Neutron features that can be packaged and lived completely isolated from Neutron
18:28:16 <prasadv> would it have same non dterministic behaviour as incubaotr
18:28:28 <s3wong> rkukura: which GBP so far is
18:28:30 <LouisF> s3wong: what sort of features?
18:28:49 <s3wong> LouisF: something like GBP, I believe
18:29:07 <rkukura> 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 <LouisF> s3wong: is there precedent for feature branches?
18:30:02 <rms_13> What is the procedure on code review on feature branch? Any decision on that yet?
18:30:09 <s3wong> LouisF: as rkukura said above, it is an idea from mestery at this point
18:30:36 <rkukura> 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 <SumitNaiksatam> 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 <prasadv> rkukura: wont (1) and (2) be the same for incubation or stackforge?
18:32:04 <rkukura> SumitNaiksatam: I think that depends if the branch is purely additive or modifies code from master/stable branches
18:32:08 <LouisF> s3wong: rkukura so feature branches are a completely new idea?
18:32:56 <s3wong> LouisF: yes, it doesn't exist today
18:33:02 <SumitNaiksatam> 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 <rkukura> 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 <SumitNaiksatam> prasadv: to your question, #link http://ci.openstack.org/stackforge.html states that stackforge projects have jenkins continuous integration support
18:35:33 <rms_13> 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 <s3wong> 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 <SumitNaiksatam> rkukura: okay, but probably related features are likely to have some overlap
18:36:22 <rkukura> 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 <rms_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 <s3wong> 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 <rms_13> 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 <rkukura> s3wong: Main difference is that graduation of a feature branch is just a merge, preserving git histrory (I think)
18:38:30 <rms_13> All I want to suggest is that we should push hard for strict rules on that front. Nothing else
18:39:13 <s3wong> rms_13: Agreed. I can definitely see another "-2: too large" or "-2: lack consensus" type situation
18:39:28 <rms_13> s3wong: +100
18:40:01 <rkukura> 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 <songole> rkukura: in that sense, stackforge is not an option
18:40:36 <SumitNaiksatam> 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 <rkukura> I think the hurdle to get into neutron is signfiicantly higher with the stackforge option than any of the others.
18:41:27 <rkukura> But there are no guarantees with any of them, meaning we could end up as a separate project.
18:41:38 <SumitNaiksatam> 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 <rms_13> rkukura: Agree. If and only if the merging guidelines is clearly defined (including review scheme)
18:42:00 <SumitNaiksatam> rms_13: i dont think anyone can gaurantee a merge :-)
18:42:11 <SumitNaiksatam> rms_13: it is an inherently subjective area
18:42:50 <rms_13> SumitNaiksatam: Than better do it on stackforge
18:42:51 <SumitNaiksatam> the principle of loose consensus allows for negative votes at any time in the liefcycle
18:43:00 <rkukura> 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 <s3wong> 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 <SumitNaiksatam> s3wong: that is good point, and Octavia, I believe has taken that view
18:44:11 <SumitNaiksatam> s3wong: they want to iterate faster, and provide something useable and put it into people’s hands
18:44:28 <rkukura> 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 <SumitNaiksatam> i also think that the approaches we are discussing are perhaps not mutually exclusive
18:45:05 <rms_13> 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 <rkukura> But as I understand it, octavia is a separate thing, basically a reference implementation of a load balancer datapath.
18:45:58 <SumitNaiksatam> rms_13: in the same way, taht for example nova interacts with neutron
18:46:41 <rkukura> To me the neutron/octavia interface isn’t that different than the neutron/ODL interface or even the nova/KVM interface.
18:47:14 <SumitNaiksatam> rkukura: i agree, octavia is not in the same zip code as a feature as GBP is
18:47:55 <SumitNaiksatam> 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 <rkukura> 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 <s3wong> rkukura: people in Octavia project (and LBaaSv2 project) has plan to spin out the entire LBaaS from Neutron
18:48:26 <s3wong> rkukura: and what is missing is a clean interface for how LBaaS uses Neutron
18:48:47 <SumitNaiksatam> s3wong: and we tried hard to fix that :-)
18:49:03 <rkukura> s3wong: Or how neutron uses LBaaS (if neutron is policy-based and controls load balancing via actions)
18:49:04 <s3wong> rkukura: thinking of NOT having GBP in Neutron can also get us to think about what external interfaces does Neutron lack
18:50:29 <rms_13> s3wong: +1
18:50:49 <prasadv> s3wong: That is a good point
18:51:11 <rkukura> To me, separate projects implies separate servers in separate processes with separate REST APIs. Is that others’ understanding as well?
18:51:44 <s3wong> rkukura: yes
18:52:09 <SumitNaiksatam> rkukura: you are asking the GBP context?
18:52:24 <SumitNaiksatam> rkukura: or a general question?
18:52:40 <rms_13> rkukura: yes
18:53:02 <rkukura> SumitNaiksatam: general, but with implications for GBP if we were to decide graduation into neutron was no longer a goal.
18:53:21 <prasadv> 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 <SumitNaiksatam> rkukura: okay
18:54:39 <rkukura> 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 <s3wong> prasadv: well, stackforge will take at least two cycles to go from incubation to mainline
18:54:45 <SumitNaiksatam> prasadv: i havent worked through a stackforge myself, there is an application process involved (i believe its just a gerrit review)
18:55:19 <s3wong> prasadv: but then again, we aren't making it to J timeframe anyway
18:55:21 <rkukura> Or are we talking about a service plugin in stackforge, that is not a separate project/server/process from neutron?
18:55:44 <SumitNaiksatam> rkukura: yes, i think we need to work through those options better
18:56:13 <rkukura> 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 <SumitNaiksatam> 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 <SumitNaiksatam> *incubation and graduation
18:56:56 <rkukura> So is “stackforge” really two different options: service plugin vs. stand-alone service?
18:57:34 <SumitNaiksatam> rkukura: perhaps
18:57:58 <SumitNaiksatam> rkukura: so lets if lbaas were to spin out today
18:58:17 <songole> is lbaasv2 being implemented as a service plugin in stackforge?
18:58:17 <SumitNaiksatam> rkukura: i think they would have to consider the same choice, right?
18:58:34 <SumitNaiksatam> songole: currently lbaasv2 is not in stackforge
18:58:47 <SumitNaiksatam> songole: it was proposed in neutron, but its in the same boat as GBP
18:58:55 <SumitNaiksatam> songole: they are evaluating the options
18:59:03 <songole> ok
18:59:17 <s3wong> songole: it isn't in stackforge yet
18:59:25 <rkukura> 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 <SumitNaiksatam> songole: what is in stackforge is Octavia, which is more of a driver/reference implemenation for lbaas
18:59:57 <SumitNaiksatam> rkukura: true
19:00:14 <SumitNaiksatam> rkukura: but i was saying in the context of the discussion in the ML
19:00:34 <SumitNaiksatam> rkukura: wherein people are accepting that the different services will be spun out into separate projects
19:00:44 <SumitNaiksatam> rkukura: eventually
19:00:46 <s3wong> SumitNaiksatam: yep, only Octavia is in stackforge, but Octavia follows LBaaSv2, and therefore it is a bit hairy
19:01:00 <SumitNaiksatam> s3wong: yes thanks
19:01:07 <SumitNaiksatam> okay folks we have hit the hour
19:01:10 <s3wong> SumitNaiksatam: so there is a LBaaS email thread that is talking about whether they should pull LBaaSv2 off there also
19:01:14 <rkukura> SumitNaiksatam: Do you mean as service plugins in separate projects, or new as new services?
19:01:28 <SumitNaiksatam> was only hoping to seed the discussion
19:01:46 <s3wong> SumitNaiksatam: yeah, no way to finalize on our plan during this meeting :-)
19:01:58 <SumitNaiksatam> 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 <rkukura> 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 <SumitNaiksatam> s3wong: yes there is an email thread to that effect
19:02:41 <SumitNaiksatam> rkukura: true, but neutron has also has a narrow defintion of what that API should be
19:02:59 <SumitNaiksatam> rkukura: so that opens up bigger questions
19:03:04 <SumitNaiksatam> alrighty folks
19:03:08 <SumitNaiksatam> lets wrap it here
19:03:09 <prasadv> SumitNaiksatam: seems like we need to decide soon on the options soon right?
19:03:16 <SumitNaiksatam> and continue on the ML
19:03:18 <SumitNaiksatam> prasadv: yes sure
19:03:32 <SumitNaiksatam> prasadv: lets leverage the ML as well
19:03:35 <s3wong> prasadv: yes, but I believe any option would at least take two cycles
19:03:43 <rkukura> 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 <prasadv> s3wong: for graduation right?
19:04:00 <SumitNaiksatam> 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 <s3wong> incubator as defined by markmcclain takes two cycles to graduate
19:04:06 <s3wong> prasadv: yes
19:04:34 <prasadv> s3wong: ok. But which option will get us in front of customers faster
19:04:49 <prasadv> I think that should be important
19:05:00 <SumitNaiksatam> prasadv: point well taken
19:05:06 <SumitNaiksatam> on that note, lets end for today
19:05:10 <SumitNaiksatam> #endmeeting