19:00:39 <mestery> #startmeeting networking_policy
19:00:41 <openstack> Meeting started Thu Apr 10 19:00:39 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:44 <openstack> The meeting name has been set to 'networking_policy'
19:00:45 <hemanthravi> hi
19:00:52 <mestery> #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#April_10.2C_2014 Agenda
19:01:07 <rkukura> hi
19:01:24 <banix> hi
19:01:36 <mestery> SumitNaiksatam mandeep: ping
19:01:37 <SumitNaiksatam> hi all
19:01:41 <SumitNaiksatam> mestery: hi
19:01:54 <rms_13> hellos
19:02:09 <mestery> So, per the agenda, lets focus on PoC updates.
19:02:15 <mestery> #topic PoC Status Updates
19:02:36 <mestery> Per SumitNaiksatam, there were some discussions ongoing this past week around this.
19:02:41 <mestery> SumitNaiksatam: Do you want to update?
19:02:48 <SumitNaiksatam> mestery: yeah sure
19:03:04 <SumitNaiksatam> so, we had discussions on two fronts
19:03:21 <nbouthors> hi
19:03:22 <SumitNaiksatam> one on the actual implementation for the PoC, and how to split the work
19:04:03 <SumitNaiksatam> second, on issues with the model itself mostly pertaining to things we have outlined in the PoC use case but having problems with representing in the current model
19:04:37 <SumitNaiksatam> on the first one, i personally made some more progress on the implementation of the model we have discussed to datee
19:04:53 <SumitNaiksatam> fixing issues, and UTs
19:05:01 <SumitNaiksatam> with inputs from banix
19:05:28 <mestery> Nice work SumitNaiksatam!
19:05:35 <SumitNaiksatam> also, rkukura and s3wong have been trying to hash out the policy enforcement
19:05:41 <SumitNaiksatam> they can update more on that
19:06:09 <SumitNaiksatam> on the second part (that is the policy model), we had expected to have a crystallized model by now
19:06:40 <SumitNaiksatam> however, we are fixing it as we go along based on the validation with the use case
19:06:52 <SumitNaiksatam> so the service redirection part is not completely baked yet
19:06:52 <mestery> That makes sense SumitNaiksatam.
19:07:19 <SumitNaiksatam> happy to answer more questions on this, but thats the high level
19:07:34 <SumitNaiksatam> will hand over to rkukura s3wong and banix
19:07:46 <hemanthravi> SumitNaiksatam: working on cli based on current model, should have an initial version fri
19:07:56 <s3wong> SumitNaiksatam: yeah, let's implement PoC based on the current model
19:07:59 <mestery> Thanks hemanthravi!
19:08:00 <SumitNaiksatam> hemanthravi: oh sweet
19:08:05 <rkukura> I don’t have much to report - just synching with SumitNaiksatam’s latest branch, making sure UTs run, etc.
19:08:21 <rkukura> s3wong and I started talking about how to divvy up work
19:08:30 <banix> hemanthravi: great; may need some changes as they come up needless to say :)
19:08:34 <hemanthravi> can i push my branch onto github
19:08:42 <hemanthravi> banix: ok
19:09:11 <s3wong> Yes, rkukura and I had preliminary division of work (high level) on the policy enforcement bit
19:09:44 <mestery> Thanks s3wong and rkukura.
19:09:53 <mestery> So, it looks like things are progressing for the PoC at this point.
19:10:34 <mandeep> mestery: Yes, SumitNaiksatam has done a great job getting the plugin started
19:10:37 <SumitNaiksatam> hemanthravi: yes, you should be able to
19:10:49 <mestery> mandeep: +1 to that1
19:11:05 <SumitNaiksatam> hemanthravi: https://github.com/noironetworks/python-neutronclient/tree/group-policy
19:11:12 <SumitNaiksatam> hemanthravi: did you face any issues?
19:11:19 <SumitNaiksatam> mandeep mestery: thanks
19:11:25 <SumitNaiksatam> long way to go
19:12:00 <hemanthravi> SumitNaiksatam: haven't tried it..working off of https://github.com/noironetworks/python-neutronclient/
19:12:09 <mestery> OK, any other PoC updates from anyone?
19:12:17 <SumitNaiksatam> hemanthravi: ok
19:12:53 <hemanthravi> and neutron from https://github.com/noironetworks/neutron-group-policy/tree/sumit/pm
19:13:05 <SumitNaiksatam> mestery: in parallel we were also having discussions on the services’ part
19:13:22 <mestery> SumitNaiksatam: Yes, I had that as an item as well with regards to getting an update.
19:13:23 <SumitNaiksatam> that is not an easy problem to solve
19:13:28 <mestery> SumitNaiksatam :)
19:13:42 <SumitNaiksatam> mestery: ok sure we can deal it as part of the agenda
19:14:10 <mestery> SumitNaiksatam: No, please, lets discuss now, I just meant I had it there as part of our smaller agenda today :)
19:14:21 <SumitNaiksatam> mestery: ok sure
19:14:23 <s3wong> SumitNaiksatam: It is however a goal of the PoC to 'redirect' to a firewall service, so at least we should iron out that soon
19:14:32 <banix> SumitNaiksatam: yes, that would be a piece we really need but have to somehow make our progress independent of that as we are trying to do
19:14:34 <SumitNaiksatam> s3wong: yeah i agree
19:15:18 <SumitNaiksatam> s3wong banix: the current thinking, from a policy perspective is to treat the service or chain as a black box
19:15:30 <SumitNaiksatam> it has some inputs and some outputs
19:15:36 <banix> SumitNaiksatam: yeah makes sense
19:15:39 <SumitNaiksatam> which could be neutron ports
19:15:43 <mestery> +1 SumitNaiksatam
19:16:02 <SumitNaiksatam> we can then incorporate this black box into the policy model
19:16:04 <mandeep> banix: s3wong: Also, as service lifecycle and discovery are not defined well at this point, there are a lot of assumptions that we will need to make about it
19:16:05 <s3wong> SumitNaiksatam: are we still redirecting to a contract scope?
19:16:20 <SumitNaiksatam> s3wong: yeah just about to say that
19:16:21 <s3wong> mandeep: no doubt :-)
19:16:59 <SumitNaiksatam> one way of doing that would be treating those neutron ports and endpoints, putting them EPGs and putting a contract around it
19:17:14 <SumitNaiksatam> we also have to pay attention to the separation of roles here
19:17:43 <SumitNaiksatam> so the “network admin” guy is the one who probably creates the network service/chains
19:18:08 <SumitNaiksatam> and he does not necessarliy need to know about the contract
19:18:13 <SumitNaiksatam> he can create the service
19:18:37 <SumitNaiksatam> and we can orchestrate the tie in to the policy model (including the creation of the EPG, contract, etc)
19:18:56 <SumitNaiksatam> the consumer in the policy world sees the contract of the service now
19:19:27 <SumitNaiksatam> so s3wong yeah, the current proposal is that redirection can happen to that contract, via the contract_scope
19:20:01 <s3wong> SumitNaiksatam: there is a possibility that we won't have 'label' for PoC though
19:20:03 <SumitNaiksatam> what happens in the black box is in the realm of the services’ discussion in neutron
19:20:08 <banix> SumitNaiksatam: why the network admin guy? thinking policies across tenants?
19:20:25 <SumitNaiksatam> banix: yes sure
19:20:30 <mandeep> s3wong: That is the machinery to allow us to reason about it, but in the common case of redirect to a service it will be "transparent" to the user
19:20:53 <SumitNaiksatam> banix: just giving an example that the network services management language is different from the policy
19:21:01 <rms_13> does a service plugin needs to be involved?
19:21:03 <banix> SumitNaiksatam: ok
19:21:29 <SumitNaiksatam> rms_13: policy plugin will leverage service plugin as a library
19:22:01 <rms_13> ok and the service plugin is going to play interface into that "black box"
19:22:10 <SumitNaiksatam> or rather thats the proposal for the PoC
19:22:28 <SumitNaiksatam> rms_13: if its a single service, yes
19:22:40 <SumitNaiksatam> rms_13: if its a chain, then the service plugin for a chain does not exist
19:22:51 <SumitNaiksatam> rms_13: actually chain does not exist in neutron :-)
19:23:35 <rms_13> ok, how do we handle that than? Onus is on controller?
19:23:52 <SumitNaiksatam> rms_13: there is no controller assumption here
19:24:03 <SumitNaiksatam> for the PoC i mean
19:24:31 <rms_13> got it
19:24:44 <mandeep> rms_13: The policy identifies what is valid, the implementation decides how to make that happen. For us to use chains, the implementation will have to do chaining first.
19:25:16 <mandeep> rms_13: And the current neutron does not have an implementation for it
19:25:34 <SumitNaiksatam> s3wong: sorry missed your earlier point on the label
19:25:39 <rms_13> I understand that. I was not sure where we are putting intellegence to do it.
19:25:58 <rms_13> plugin or its driver or controller
19:26:13 <s3wong> SunitNaiksatam: it is OK, mandeep commented on it above :-)
19:26:33 <SumitNaiksatam> s3wong: cool
19:26:51 <mandeep> rms_13: For now we are working on balckbox service (for the PoC), so have punted on that for next couple of weeks ;-)
19:27:05 <rms_13> :), perfect
19:27:31 <s3wong> SumitNaiksatam: for what I need to do in PoC, I just want to know that user will definitely 'redirect' to a contract scope; thus I need to render it to something
19:27:55 <s3wong> SumitNaiksatam: so I just want to make sure the current model still holds, even in the case where there isn't yet a concept of 'label' during PoC
19:28:13 <mandeep> s3wong: Yes, that looks right
19:28:40 <s3wong> mandeep: cool
19:30:08 <mestery> OK, lots of good discussions here.
19:30:27 <mestery> Anything else PoC related to discuss? Otherwise, that's all I had on the agenda at the moment.
19:30:28 <mestery> :)
19:30:45 <banix> If you consider the policy along with all the required pieces on the services side, it seems to me if (when :)) we pull this off it will be a monumental task that can make a significant shift in how we do networks. Am I being carried away here or you feel the same way?
19:30:51 * s3wong thinks mestery wants to once again end the meeting early
19:30:57 <mestery> s3wong: :P
19:31:05 <mestery> s3wong: Just noticed 2 minutes of silence there :)
19:31:06 <SumitNaiksatam> banix: :-)
19:31:23 * mestery thinks banix is waxing philosophical. :)
19:31:31 <SumitNaiksatam> banix: that sounded like a drum roll :-)
19:31:34 <s3wong> banix: we are changing the world (starting by changing Neutron, which is already tough)
19:31:38 <banix> :)
19:31:40 <mandeep> banix: If we can move the networking to a more declarative devops model, yes I think that will be a welcome change
19:31:53 <mestery> +1 to change!
19:32:02 <rms_13> +1 to change!
19:32:02 <banix> mandeep: now that is a more measured declaration
19:32:19 <mandeep> ;-)
19:32:51 <rms_13> Would like to play devil's advocate here; Since we are abstracting the hack out of network constructs :), will community argue that neutron is not a place for you!?
19:32:52 <s3wong> mandeep: so in declarative term, we are trying to change networking (defining goal and behavior). How to do it is up to us :-)
19:33:27 <banix> rms_13: yes they will; parts of the community that is
19:33:54 <banix> that was mentioned during the sumit in Hong Kong
19:34:17 <mandeep> rms_13: That looks good in abstract, but when you get to specifics there are things that belong with how networking is implemented (hence Neutron) and things that should be at a higher governance model
19:34:18 <mestery> rms_13: I think it's fair to say that starting with networking is a good idea.
19:34:39 <s3wong> banix: absolutely. There was definitely a lot of resistance during the I-Summit. But I do feel the mindset has changed a lot since then
19:34:46 <banix> and I think the other side of the coin is if this proves valuable shouln't we get away from the current model
19:35:17 <mestery> banix: Current model being networks/subnets/ports etc.?
19:35:26 <banix> mestery: yes
19:35:31 <mestery> banix: If so, yes, I think there is much interest in moving past those constructs in the community.
19:35:38 <mandeep> By using an interception model for current interface, we can make that transition incremental. Otherwise, we will not be able to convince anyone
19:35:39 <mestery> I've spoken with many who are on board with something like that.
19:35:51 <SumitNaiksatam> i think we are mixing two things here
19:36:00 <mestery> mandeep: +1
19:36:03 <SumitNaiksatam> there are users in different roles
19:36:17 <rms_13> banix: I think its better to cover the whole spactrum (eventually  fixing the other end which is broken)
19:36:21 <SumitNaiksatam> the group policy model is for the consumption of the “app” user
19:36:40 <SumitNaiksatam> there is a place for the elemental neutron network constructs too
19:36:47 <rms_13> +1
19:37:00 <rms_13> Just that it requires repairs
19:37:07 <mestery> SumitNaiksatam: Agreed, I was trying to convey that there are deployers who have expressed interest in using the GBP model in Neutron. :)
19:37:16 <banix> Yes we are not advocating abondoning the current model
19:37:17 <SumitNaiksatam> mestery: exactly
19:37:24 <SumitNaiksatam> mestery: and this is to address that
19:37:42 <mestery> SumitNaiksatam: +1
19:38:11 <s3wong> mestery: speaking of networking first - I remember a month or so ago you were going to have someone from Nova joining us and talk about compute scheduling policy
19:38:25 <banix> but as we prepare for the summit we need to have answers for that type of question
19:38:44 <rms_13> s3wong: thanks for bringing that up
19:38:49 <SumitNaiksatam> banix: agreed
19:38:56 <mestery> s3wong: Yes, that person disappeared after announcing some interest, let me reach out again and see if there is still interest there.
19:39:07 <s3wong> is there still interest with Nova side to exchange knowledge on our respective policy models?
19:39:17 <s3wong> mestery: cool
19:39:22 <banix> mestery: s3wong yeah there have been some work on that side on policies and groups
19:39:46 <banix> it would be good to know more; also work and proposals on the Heat side that we need to be aware of
19:40:04 <s3wong> banix: absolutely. That would be great
19:40:10 <SumitNaiksatam> probably the discussion with the nova folks will be easier once we have the PoC
19:40:23 <SumitNaiksatam> that makes is a little more concrete for people to understand
19:40:25 <rms_13> I am not sure about our strategy on communication with Nova here with gbp.
19:40:58 <rms_13> They require network info in specific form and our abstraction might be forced to provide it
19:41:07 <rms_13> But will that be a good design?
19:41:10 <s3wong> SumitNaiksatam: it would be easier to communicate with the rest of the Neutron community too with a PoC :-)
19:41:15 <banix> another fron that we were hoping to get more input from experts wa QoS
19:41:19 <rms_13> If I am off the topic; punt it for later please
19:41:42 <mestery> rms_13: Nova/Neutron interfaces have a history, but agreed, this will necessitate bringing nova folks on board.
19:41:43 <banix> now we are not focused on QoS right now but we have to keep that "action" in mind
19:41:46 <SumitNaiksatam> s3wong: yes sure :-) i think we got the work cut out on that front
19:41:47 <s3wong> banix: yes, good point. We should reach out to Sean to meet with him during the J-Summit
19:41:51 <mestery> rms_13: As SumitNaiksatam said, once we have the PoC, that will be easier to explain
19:42:33 <rms_13> mestery: ok
19:43:35 <rms_13> 2 min of silence :)
19:43:37 <banix> s3wong: sounds good
19:43:52 <s3wong> mestery: definitely going radio silence now...
19:43:58 <mestery> s3wong: :P
19:44:03 <mestery> OK, should we wrap things up for this week?
19:44:07 <rms_13> +!
19:44:09 <s3wong> +1
19:44:10 <banix> yes!
19:44:45 <mestery> OK, thanks folks! We'll talk to you all next week and in the ML/IRC!
19:44:49 <mestery> #endmeeting