18:07:08 <SumitNaiksatam> #startmeeting networking_policy
18:07:09 <openstack> Meeting started Thu Sep 11 18:07:08 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:07:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:07:12 <openstack> The meeting name has been set to 'networking_policy'
18:07:16 <SumitNaiksatam> apologies for the delay in starting!
18:07:26 <rms_13> np
18:07:26 <SumitNaiksatam> #info agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
18:07:35 <s3wong> SumitNaiksatam: may want to make banix chair too in case you drop out :-)
18:07:41 <SumitNaiksatam> yes yes
18:08:05 <SumitNaiksatam> #chairs banix s3wong rkukura_ rms_13 ivar-lazzaro LouisF
18:08:22 <SumitNaiksatam> there, thanks for reminding s3wong :-)
18:08:30 <SumitNaiksatam> #topic Status update
18:08:49 <SumitNaiksatam> so we are going through a process of validating the patches that we have posted
18:08:56 <SumitNaiksatam> let me start with ivar-lazzaro
18:09:08 <ivar-lazzaro> SumitNaiksatam: yup
18:09:11 <SumitNaiksatam> he has been spending quite a bit of time with testing the data path
18:09:16 <SumitNaiksatam> ivar-lazzaro: thanks for jumping in
18:09:28 <SumitNaiksatam> ivar-lazzaro: go ahead, cna you please update us with your findings?
18:09:29 <s3wong> ivar-lazzaro: yes, thank you
18:09:42 <ivar-lazzaro> SumitNaiksatam, s3wong: no problems
18:09:43 <SumitNaiksatam> s3wong: thanks for bringing up up to speed as well
18:10:02 <ivar-lazzaro> I've just pushed a rebase on the whole GBP series, together with some fixes in the DB migration
18:10:27 <ivar-lazzaro> and some changes in how SGs are mapped through contracts
18:10:31 <SumitNaiksatam> ivar-lazzaro: nice
18:10:39 <SumitNaiksatam> ivar-lazzaro: and you had some success with the testing?
18:10:42 <ivar-lazzaro> The validation is going well so far, I'm able to get traffic for simple setup
18:10:48 <SumitNaiksatam> ivar-lazzaro: nice
18:10:52 <s3wong> ivar-lazzaro: great!
18:11:03 <ivar-lazzaro> So everything smooth so far :)
18:11:21 <SumitNaiksatam> ivar-lazzaro: that’s in part thanks to your effort! ;-)
18:11:41 <SumitNaiksatam> ivar-lazzaro: you were also making a point about using remote SG ids in the SG mapping?
18:12:01 <ivar-lazzaro> SumitNaiksatam: correct
18:12:26 <ivar-lazzaro> So looking at the implementation, I'm afraid we could get into some troubles when overlapping IPs are enabled
18:12:34 <s3wong> ivar-lazzaro: right, I briefly looked at the changes, seems like you are still using CIDR/remote-ip-prefix?
18:12:51 <ivar-lazzaro> which means that some EPGs might be able to reach others even without sharing the same contract
18:13:09 <ivar-lazzaro> s3wong: yes, I want to know what the rest of the team thinks
18:13:22 <ivar-lazzaro> s3wong: before going that route
18:13:34 <banix> ivar-lazzaro: can you post the link to the updated version please
18:13:39 <rkukura_> Overlapping IPs of different tenants that are completely isolated from each other should be OK
18:13:40 <s3wong> ivar-lazzaro: I have no objection - it actually will simplify the implementation a bit
18:13:53 <SumitNaiksatam> s3wong: you mentioned that you had discussed this with rkukura_?
18:13:55 <ivar-lazzaro> banix: searching
18:14:02 <SumitNaiksatam> banix: the patch series is updated
18:14:20 <ivar-lazzaro> banix: #link https://review.openstack.org/#/c/113775/
18:14:25 <banix> ivar-lazzaro: thanks
18:14:30 <s3wong> SumitNaiksatam: rkukura_: yes. rkukura_ -- if you remember, during the hackathon, we visited the remote-SG option, but we opted not to go with it
18:14:40 <s3wong> rkukura_: but I don't remember the reason... do you?
18:15:06 <rkukura_> I had concerns
18:15:11 <ivar-lazzaro> rkukura_: well in theory, as long as you are using a different l3_context you can have overlapping subnets right?
18:15:15 <rkukura_> My concerns were mainly about efficiency
18:16:02 <rkukura_> If using SG IDs means there is a separate iptables rule for each IP addr rather than for each subnet, then it will not scale well
18:16:03 <ivar-lazzaro> rkukura_: can you expand on that?
18:16:57 <SumitNaiksatam> rkukura_: ah, so you wanted to avoid the remote SG since the SG implementation maps that to specific iptables rules
18:17:26 <SumitNaiksatam> rkukura_: whereas we could be more intelligent in the way we craft the CIDRs and reduce the number of rules
18:17:28 <rkukura_> I don’t see how the SG implementation could know how GBP is using subnets, and that matching the prefix is a valid optimization
18:17:37 <SumitNaiksatam> rules -> iptables rules
18:17:38 <rkukura_> right
18:18:10 <rkukura_> The whole reason we are mapping EPGs to one or more subnets is to enable this optimization
18:18:19 <SumitNaiksatam> rkukura_: makes sense
18:18:33 <SumitNaiksatam> rkukura_: ivar-lazzaro is treating the SG implementation as blackbox
18:18:35 <ivar-lazzaro> rkukura_: thanks! those are all valid points
18:19:15 <SumitNaiksatam> rkukura_: and if we assume that the SG mapping/implementation is optimal, then using remote SG makes it much more easier to maintain consistency
18:19:40 <SumitNaiksatam> rkukura_: but perhaps the assumption is not correct from an optimality perspective
18:19:44 <rkukura_> But the SG implementation cannot know that all IPs in a subnet will be treated the same!
18:19:52 <SumitNaiksatam> rkukura_: ok
18:20:06 <SumitNaiksatam> ivar-lazzaro: lets think about it more
18:20:19 <rkukura_> We are also going to need ways to treat external subnets as EPGs, right?
18:20:20 <s3wong> rkukura_: ivar-lazzaro: SumitNaiksatam: consensus then? Going with current implementation?
18:20:22 <SumitNaiksatam> and discuss with rkukura_ and s3wong
18:20:31 <s3wong> SumitNaiksatam: OK
18:20:40 <SumitNaiksatam> s3wong: i dont think ivar-lazzaro has changed that part of the implementation yet
18:21:02 <ivar-lazzaro> SumitNaiksatam: yeah, I was also concerned on how many new rules you have to add to the existing SGs when a new subnet is added to an EPG
18:21:22 <s3wong> SumitNaiksatam: yes, I know. Just wanting to get to a decision point :-)
18:21:29 <SumitNaiksatam> s3wong: :-)
18:21:33 <ivar-lazzaro> SumitNaiksatam: which would come for free with the remote SG. But I agree that we need to look for the most scalable solution
18:21:49 <rkukura_> I think we can tune the subnet size to avoid scaling issues, especially with private address spaces
18:22:01 <SumitNaiksatam> ivar-lazzaro: yeah, i think this requires more discussion than the short time available here
18:22:14 <s3wong> ivar-lazzaro: yes - and I have not implemented that in update_epg (with a TODO :-) )
18:22:18 <SumitNaiksatam> ivar-lazzaro: thanks for the update
18:22:28 <ivar-lazzaro> SumitNaiksatam: agree!
18:22:34 <SumitNaiksatam> i dont think there is any update on the model side from me, or from rkukura_ on the mapping
18:22:44 <ivar-lazzaro> s3wong: TODO is the same as being already there :p
18:22:54 <SumitNaiksatam> s3wong: and ivar-lazzaro are collaborating on validating the SG mapping
18:22:57 <SumitNaiksatam> as we just discussed
18:23:20 <SumitNaiksatam> the CLI is being tested as we are validating this
18:23:42 <SumitNaiksatam> and ivar-lazzaro found an issue with clearing the “provided/consumed” contracts dict in the EPG
18:23:51 <SumitNaiksatam> so that needs to be fixed
18:23:59 <SumitNaiksatam> i believe songole is working on it as we fix
18:24:11 <ivar-lazzaro> SumitNaiksatam: great!
18:24:15 <SumitNaiksatam> other than that CLI is operational to the extent we have tested it
18:24:30 <SumitNaiksatam> rms_13: Horizon :-)
18:24:36 <rms_13> Yes
18:24:55 <rms_13> Working on your complain about horizon not starting :)
18:25:02 <rms_13> Should have update in 1 hr
18:25:18 <SumitNaiksatam> rms_13: sweet, it was not a complain, just an observation! ;-P
18:25:33 <rms_13> My VM with new code just came up so looking into it...may be I will have answer towards end of this meeting....
18:25:42 <SumitNaiksatam> rms_13: awesome
18:25:49 <rms_13> yeah.. no worries...will be fixed
18:26:04 <SumitNaiksatam> rms_13: i know you are swamped with other things on your plate as well
18:26:12 <SumitNaiksatam> rms_13: so thanks for doing this for the team!
18:26:26 <rms_13> SumitNaiksatam: happy to be part
18:26:45 <SumitNaiksatam> i am not sure if susant is here
18:27:03 <SumitNaiksatam> i believe he updated the Heat patch as well, but i am not sure how complete that is
18:27:54 <SumitNaiksatam> oh it seems like he posted a second patch: #link https://review.openstack.org/#/c/120862/
18:28:07 <SumitNaiksatam> LouisF: i know you were interested in tracking this ^^^
18:28:24 <SumitNaiksatam> the first patch was #link https://review.openstack.org/#/c/111419/3
18:28:45 <SumitNaiksatam> everything is still documented in our wiki page: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches
18:29:11 <LouisF> yes
18:29:43 <LouisF> will review
18:29:46 <SumitNaiksatam> i have not tested the Heat part, perhaps LouisF you can help?
18:29:56 <LouisF> ok
18:31:12 <SumitNaiksatam> btw, if someone wants to run devstack pointing to the above branches, the following local.conf might work
18:31:18 <SumitNaiksatam> #link https://gist.github.com/snaiksat/0ce525f8f57f84574793
18:31:40 <SumitNaiksatam> you might need to update the patch references and the patch set numbers
18:31:51 <SumitNaiksatam> LouisF: the above might help if you are testing Heat
18:32:28 <SumitNaiksatam> any other updates we want to cover in terms of the current implementation?
18:32:47 <LouisF> thx
18:33:04 <SumitNaiksatam> #topic Next steps discussion
18:33:56 <SumitNaiksatam> based on the feedback in the ML over the past week, it seemed like the stackforge repo is needed regardless of which direction we tak
18:33:59 <SumitNaiksatam> *take
18:34:15 <SumitNaiksatam> so we do have the stackforge repo now: #link http://lists.openstack.org/pipermail/openstack-dev/2014-September/045423.html
18:34:37 <SumitNaiksatam> we do have repos for the client and the specs as well
18:34:52 <SumitNaiksatam> there is more discussion going on the same thread
18:35:07 <ivar-lazzaro> SumitNaiksatam: nice! Thanks for working on this
18:35:27 <SumitNaiksatam> there was an email from rkukura_ earlier today and some follow up from kevinbenton mandeep and s3wong
18:35:59 <rkukura_> yes, basically a last ditch effort to avoid stackforge
18:36:04 <SumitNaiksatam> rkukura_: okay
18:36:43 <rkukura_> but I agree with others that if the community isn’t ready to invest reviewer cycles in GBP, there isn’t another option
18:36:46 <SumitNaiksatam> rkukura_: i would interpret as a last ditch effort to keep the other options alive
18:37:20 <SumitNaiksatam> rkukura_: it seems like for us to be able to experiment we would always need the flexibility of stackforge in parallel
18:37:27 <LouisF> rkukura_: what are your main concerns about stackforge?
18:37:39 <rkukura_> I’m not convinced there is any reasonable possibility to move significant code developed outside the neutron repo into the neutron repo.
18:37:54 <banix> LouisF: staying there for good
18:38:39 <SumitNaiksatam> rkukura_: banix: can we not introduce the features that are in stackforge into the feature branch or the incubator?
18:39:34 <rkukura_> I think we’d need to tear it apart into reviewable patches, which is a huge effort, and we’d likely have to make design changes as we go.
18:39:50 <banix> SumitNaiksatam: yes, that would be essentially using other options.
18:39:56 <rkukura_> Reviews would want changes, would effect all the subsequent patches.
18:40:29 <rkukura_> So it would basically be a re-implementation in the neutron repo.
18:40:35 <SumitNaiksatam> rkukura_: but it seems that we would have to follow that approach regardless
18:41:00 <banix> rkukura_: that is one long email :) ned to read carefully after the call
18:41:15 <rkukura_> I was hoping we’d find a way to get the code reviewed as we develop it, rather than after its all done.
18:41:33 <SumitNaiksatam> rkukura_: we are already one with the code :-)
18:41:37 <rkukura_> banix: I abandoned at much longer version
18:41:45 <SumitNaiksatam> rkukura_: at least a major part of it
18:42:12 <rkukura_> SumitNaiksatam: You have a point, but at least its a series of patches that have already been through substantial review
18:42:20 <rkukura_> at least some of them
18:42:28 <SumitNaiksatam> rkukura_: true
18:43:00 <rkukura_> if we take them to stackforge and then try to bring them back, we’ll be starting over on the reviews, and may need to split it into API subsets again, etc.
18:43:22 <ivar-lazzaro> rkukura_: well I think that the main point here is to try to get as many people as possible using it, In order to validate the model and gain consensus
18:43:26 <banix> rkukura_: agree
18:43:37 <SumitNaiksatam> rkukura_: hopefully the quality of the code matters
18:43:51 <rkukura_> ivar-lazzaro: I can’t disagree with that, and stackforge may be the only workable short term option
18:43:54 <ivar-lazzaro> rkukura_: that certainly doesn't come without a merging effort, but it may happen in the neutron incubator as well after the details are set
18:44:19 <SumitNaiksatam> rkukura_: if its been baked, then we can hope that it will be a shorter review cycle
18:44:33 <rkukura_> I think the fundemental question is whether the neutorn community wants to devote core review time at this point
18:45:03 <rkukura_> SumitNaiksatam: We can hope, but the “I’d have done it differently” syndrome scares me.
18:45:06 <SumitNaiksatam> rkukura_: yes, i think that is one of the fundamental questions
18:45:27 <banix> i think what we need to revsist is how we bring in the rest of the community, that is the rest of the cores. not necessarily agreeing on having GBP but as what the process should be to see if we can get there
18:46:03 <SumitNaiksatam> banix: those two see to go hand in hand
18:46:25 <SumitNaiksatam> banix: agreeing on how to get a feature into neutron, would depend on whether there is belief in the feature
18:46:46 <ivar-lazzaro> banix: I think that part of that effort is having an implementation that people can use, so that we can get feedback on it
18:46:46 <SumitNaiksatam> banix: if there isnt belief, then the process probably does not work
18:46:55 <SumitNaiksatam> banix: as we have realized in the last cycle
18:46:57 <ivar-lazzaro> SumitNaiksatam: exactly
18:47:10 <SumitNaiksatam> banix: i think the process was followed, and no one disputed that
18:47:36 <banix> SumitNaiksatam: I think what we heard at least from some was we are not convinced but we are open to explore; in that spirit we should engage them
18:48:08 <SumitNaiksatam> but i believe the feedback was that people need to use this and tell us that this is useful
18:48:40 <ivar-lazzaro> +1
18:48:55 <SumitNaiksatam> banix: true
18:49:23 <banix> SumitNaiksatam: yes that was part of it as well. so the question is if with going through StackForge we may cover that usage part a bit better but lose in other fronts
18:49:23 <SumitNaiksatam> banix: hence i think it behooves us to give those people something that they can use and explore
18:50:02 <LouisF> ODL is moving ahead with a GBP implementation  - does that indicate that there is significant interest?
18:50:04 <ivar-lazzaro> I agree that we might get to the point in which the merging effort would become great… But that may be well spent time as long as we have a broader consensus that the feature is cool and that it should be into Neutron
18:50:06 <banix> SumitNaiksatam: sure; all i am saying is we should continue engaging Neutron and follow up on incubator/feature branch options
18:50:55 <SumitNaiksatam> banix: yeah, at least my point is that the stackforge option is not necessarily mutually exclusive
18:51:07 <SumitNaiksatam> banix: or for that matter any option
18:51:07 <ivar-lazzaro> banix: agree, those options are always open
18:51:37 <SumitNaiksatam> LouisF: good point, but i am not sure its ready, and/or when it will be
18:51:49 <banix> SumitNaiksatam: yes, i think we can make it that way; will require us having that mind set
18:51:50 <SumitNaiksatam> LouisF: so it might not be an immediate data point that can be used here
18:52:38 <SumitNaiksatam> stackforge is also an option to explore
18:53:17 <SumitNaiksatam> so we will hopefully get better understanding from having something working, and the feedback we gain that be used in how we make progress
18:54:19 <SumitNaiksatam> currently we are bit constrained on the technical options
18:54:37 <SumitNaiksatam> anyway, we are getting close to the hour
18:54:49 <rkukura_> I don’t see any reason we shouldn’t move forward immediately on figuring out exactly how we’d structure things in stackforge. If this seems reasonable and its not looking like any better option is going to be available, then we should merge the patches into stackforge and iterate there.
18:55:08 <SumitNaiksatam> rkukura_: okay
18:55:23 <banix> SumitNaiksatam: agree
18:56:13 <SumitNaiksatam> so lets start thinking in terms of what the stackforge structure would look like
18:56:32 <SumitNaiksatam> we probably dont have enough time to discuss in this meeting
18:56:55 <SumitNaiksatam> one of the imperatives there is that we do need to be able to package this with Juno
18:57:02 <SumitNaiksatam> so that we can reach the users at the earliest
18:57:10 <ivar-lazzaro> +1
18:57:11 <SumitNaiksatam> so we need to factor that in
18:57:21 <SumitNaiksatam> btw, the above was more like an open discussion
18:57:31 <SumitNaiksatam> so we will not have a separate agend topic for that
18:57:49 <SumitNaiksatam> but if anyone has any other point/issue to raise, please feel free to do so
18:57:59 <SumitNaiksatam> we still have 3 mins ;-P
18:58:58 <LouisF> s3wong: can you elaborate on remote SG?
18:59:23 <SumitNaiksatam> LouisF: it might take a little longer
18:59:29 <SumitNaiksatam> LouisF: would a follow up email work?
18:59:34 <LouisF> ok
18:59:35 <rkukura_> Is our goal in stack forge to deliver an add-on GBP service plugin on top of both the stable/juno and master neutron branches?
18:59:51 <SumitNaiksatam> rkukura_: i guess thats open for discussion
19:00:03 <rkukura_> along with the client, horizon, heat, etc support?
19:00:03 <SumitNaiksatam> rkukura_: i mean we at least need stable/juno
19:00:09 <SumitNaiksatam> rkukura_: the latter yes
19:00:18 <SumitNaiksatam> rkukura_: but we cannot wait for stable/juno to be cut
19:00:32 <rkukura_> we’d start with juno-rc1 I’d think
19:00:41 <SumitNaiksatam> rkukura_: why not J3?
19:01:00 <rkukura_> either way, depending on timing
19:02:00 <SumitNaiksatam> we are over time
19:02:09 <SumitNaiksatam> rkukura_: lets follow up on that
19:02:14 <SumitNaiksatam> anything else?
19:02:31 <banix> thanks all
19:02:44 <SumitNaiksatam> okay, thanks everyone for joining!
19:02:47 <banix> bye
19:02:47 <SumitNaiksatam> #endmeeting