18:01:42 <SumitNaiksatam> #startmeeting networking_policy
18:01:43 <openstack> Meeting started Thu May  8 18:01:42 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:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:46 <openstack> The meeting name has been set to 'networking_policy'
18:01:55 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
18:02:03 <SumitNaiksatam> #topic GP bp spec review
18:02:12 <SumitNaiksatam> #link https://review.openstack.org/#/c/89469
18:02:27 <SumitNaiksatam> this was merged
18:02:43 <SumitNaiksatam> thanks all for contributing and working towards this
18:02:57 <SumitNaiksatam> an important milestone in the process
18:03:22 <banix> SumitNaiksatam: great. thanks to you for all your work as well
18:03:37 <SumitNaiksatam> banix: thanks, great team effort
18:03:44 <SumitNaiksatam> so we have to transition to the next step for pushing the patches
18:03:53 <rkukura> hi
18:04:03 <SumitNaiksatam> rkukura: hi
18:04:16 <SumitNaiksatam> we are obviously already working towards that
18:04:18 <mandeep> SumitNaiksatam: hi
18:04:23 <SumitNaiksatam> mandeep: hi
18:04:30 <SumitNaiksatam> our PoC is a step in that direction
18:04:51 <SumitNaiksatam> lets first touch quickly on the model
18:04:57 <SumitNaiksatam> #topic Policy Model
18:05:07 <SumitNaiksatam> we made some minor tweaks
18:05:20 <SumitNaiksatam> i am referring to the EPG to Contract relationship change
18:05:32 <SumitNaiksatam> most of you already know this
18:05:36 <SumitNaiksatam> just reiterating here
18:06:03 <SumitNaiksatam> the ContractProvider/ConsumerScope is now optional when specifying the relationship
18:06:37 <SumitNaiksatam> so you can say EPG X consumes/provides Contract Y (without having to create the relationship object)
18:07:05 <SumitNaiksatam> this probably makes it much simpler and easier to incrementally consume this model
18:07:24 <banix> I agree
18:07:43 <SumitNaiksatam> banix: thanks, yeah i mostly heard everyone in agreement with this change
18:07:56 <Louis_> so a contract can consume a list of EPGs?
18:08:13 <SumitNaiksatam> Louis_: er…its the other way around
18:08:14 <mandeep> Yes, agreed
18:08:18 <SumitNaiksatam> mandeep: ok
18:08:33 <SumitNaiksatam> Louis_: EPGs can consume one or more Contracts
18:09:23 <SumitNaiksatam> ok, just wanted to highlight that change
18:09:42 <SumitNaiksatam> if no other thoughts/questions, then moving on
18:09:44 <Louis_> ok, so a EPG can provide one or more contracts?
18:10:00 <SumitNaiksatam> Louis_: yes (and/or consume one or more contracts)
18:10:32 <s3wong> we lost SumitNaiksatam
18:10:33 <Louis_> is this shown in an updated model diagram?
18:10:58 <mandeep> Let us wait for SumitNaiksatam to join
18:11:02 <Louis_> is this shown in an updated model diagram?
18:11:03 <SumitNaiksatam> sorry, i got bumped out
18:11:13 <SumitNaiksatam> Louis_: yes
18:11:41 <SumitNaiksatam> Louis_: see: https://docs.google.com/a/noironetworks.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit?pli=1#slide=id.g1d6aae2d8_5651
18:11:54 <SumitNaiksatam> and: https://docs.google.com/a/noironetworks.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit?pli=1#slide=id.g12c5a79d7_4044
18:13:14 <SumitNaiksatam> Louis_: looks okay?
18:13:52 <SumitNaiksatam> Louis_: perhaps we can come back to this
18:14:13 <SumitNaiksatam> #topic PoC Status Update
18:14:25 <SumitNaiksatam> #info PoC branch is: https://github.com/noironetworks/neutron-group-policy/tree/group-policy-poc
18:14:40 <SumitNaiksatam> we are full steam ahead on this
18:15:00 <SumitNaiksatam> yesterday we created the first EPG and EP!
18:15:03 <SumitNaiksatam> yay!
18:15:07 <mandeep> +1
18:15:14 <SumitNaiksatam> baby steps
18:15:18 <s3wong> amazing
18:15:25 <SumitNaiksatam> thanks all
18:16:00 <SumitNaiksatam> so as of now, EPG, EP, Contract, Policy Rule, Policy Classifier, and Policy Action resources are implemented
18:16:12 <SumitNaiksatam> this is what we will have in the first iteration
18:16:17 <mandeep> It was a significant integration across devstack, python-neutronclient + CLI, group-policy manager + plugin, ... so a good ene-toend flowe
18:16:23 <rkukura> also BD and RD
18:16:25 <SumitNaiksatam> mandeep: +1
18:16:33 <SumitNaiksatam> rkukura: yes, thanks!
18:16:47 <SumitNaiksatam> rkukura: i only keep thining about the app guy! :-P
18:16:53 <SumitNaiksatam> *thinking
18:17:18 <rkukura> SumitNaiksatam: need to do a bit more of that myself ;)
18:17:22 <Louis_> ok i see the provided_contracts/consumed_contracts list in the EPG REST table
18:17:39 <SumitNaiksatam> rkukura: we need the balance :-)
18:17:50 <SumitNaiksatam> Louis_: yes
18:18:07 <SumitNaiksatam> on the model implementation, there are things which are not tested yet
18:18:14 <SumitNaiksatam> like the Contract hierarchy
18:18:19 <marun> still not on gerrit :p
18:18:29 <SumitNaiksatam> marun: getting there :-)
18:18:36 <marun> that should be the first step, not the last.
18:18:48 <marun> I guarantee patch review is going to be more complicated by this path.
18:19:00 <marun> But, sometimes lessons need to be learned the hard way :)
18:19:28 <SumitNaiksatam> marun: well its not yet ready for gerrit yet, there are many moving peices and we are in teh process validating how well the peices fit
18:19:40 <SumitNaiksatam> marun: hence this is called a PoC
18:19:55 <marun> disagree entirely
18:20:06 <marun> but we can agree to disagree
18:20:08 <SumitNaiksatam> marun: we dont want to waste reviewers cycles on things which are not baked
18:20:14 <marun> 'waste time'?
18:20:17 <marun> you mark it as 'WIP'
18:20:18 <SumitNaiksatam> marun: absolutely
18:20:27 <marun> or 'DRAFT'
18:20:51 <marun> working outside of gerrit limits visibility to the subteam, and that's not a good thing.
18:21:01 <marun> it also encourages monolithic changes without oversight.
18:21:02 <SumitNaiksatam> marun: disagree
18:21:11 <marun> all of which will bite in actual review
18:21:19 <marun> as you will see soon enough :)
18:21:31 <rkukura> marun: We could push the whole thing as a single WIP review on gerrit, but will probably want to push the real code in smaller chunks for review
18:21:33 <SumitNaiksatam> marun: that sounds more like a threat!
18:21:42 <marun> take it as you will
18:21:58 <SumitNaiksatam> marun: not a very constructive to phrase it
18:22:01 <SumitNaiksatam> ok moving on
18:22:05 <marun> I hold all feature additions to the same standards.
18:22:32 <SumitNaiksatam> marun: as does everyone else here
18:22:43 <marun> If only!
18:22:48 <SumitNaiksatam> rkukura: over to you on the mapping implementation
18:23:24 <banix> rkukura: can you give a two line brief description of the mapping work if you don’t mind
18:23:35 <SumitNaiksatam> rkukura: great progress on the keeping in sync with the model changes
18:24:43 <rkukura> ok
18:24:59 <rkukura> basically, the mapping does two things now:
18:25:35 <rkukura> first, if an EPG is created without passing in a BD, one is implicitly created for the EPG
18:26:31 <rkukura> similarly, if a BD is created (implicitly or explicitly) and no RD is passed in, a default RD for the tenant is created/found
18:27:20 <rkukura> second, the RD is mapped to a neutron router, the BD is mapped to a neutron network, the EPG is mapped to  a neutron subnet, and the EP is mapped to a neutron port
18:28:06 <rkukura> so we were able to use the GP API to create an EPG, create an EP in it, and then get a port for EP and use it to launch  a nova VM
18:28:14 <banix> thanks rkukura for the summary
18:28:20 <rkukura> that’s basically where the mapping stands
18:28:51 <rkukura> we’re starting to work on mapping the policy to SG and FW rules
18:29:17 <SumitNaiksatam> also some aspects of the mapping are configuration driven
18:29:23 <SumitNaiksatam> rkukura: great summary
18:29:42 <Louis_> why is there a 1-1 binding and a many-many association between a RD and a router?
18:29:45 <banix> the BD and RD are created implicitly. right? at least that is the desired workflow?
18:30:07 <SumitNaiksatam> banix: yes
18:30:16 <rkukura> banix: either implicit or explicit BR and RD creation should work
18:30:31 <SumitNaiksatam> banix: however its possible to provide them explicitly as well
18:30:42 <rkukura> Louis_: Right now, I think the mapping will use one router per RD
18:30:43 <banix> ok thanks
18:30:53 <SumitNaiksatam> Louis_: RD to routers is 1:many
18:31:15 <rkukura> would be good to know if we really need multiple routers in a single RD
18:31:35 <Louis_> i see in the code there is both a binding and an association
18:31:37 <SumitNaiksatam> rkukura: there might be use cases
18:31:45 <SumitNaiksatam> Louis_: good question
18:32:00 <SumitNaiksatam> Louis_: we want to remove the association
18:32:09 <rkukura> we allow multiple subnets per EPG in order to support adding more EPs than one subnet will hold
18:33:22 <s3wong> rkurkura: certainly makes it easier for me to just fetch the router via context
18:33:42 <rkukura> agreed we should remove both association tables from the DB model if we can
18:33:54 <SumitNaiksatam> rkukura: yeah
18:34:29 <SumitNaiksatam> any more thoughts/questions on the mapping?
18:34:38 <rkukura> s3wong: Unless we have a use case for the PoC, I think we should limit the PoC to one router per RD
18:34:46 <banix> just a general question on the model:
18:34:51 <SumitNaiksatam> rkukura: yes, agree
18:34:52 <Louis_> wouldn't it be better to remove the binding?
18:34:56 <s3wong> rkukura: and I do not disagree with that :-)
18:35:06 <banix> we had discussed this early on but not recently. what is the connectivity within an EPG?
18:35:19 <Louis_> and just have the association?
18:35:40 <SumitNaiksatam> Louis_: its actually not a many:many to relationship
18:35:57 <SumitNaiksatam> Louis_: RD to routers, that is
18:36:12 <rkukura> s3wong: do you see an immediate need for multiple routers in the same RD? If so, we should talk about how we decide which one(s) the EPG’s subnets get connected to, which I’m working on today
18:36:51 <SumitNaiksatam> rkukura s3wong: i think in the implicit workflow, one router is good
18:36:54 <s3wong> rkukura: no, there isn't. We should focus on getting contract done. One per RD is definitely good for PoC
18:37:07 <SumitNaiksatam> banix: EPs within EPG have connectivity
18:37:39 <banix> SumitNaiksatam: they do in our implementation but in the model?
18:38:03 <SumitNaiksatam> banix: this behavior can be overriden by setting attributes in teh BD
18:38:26 <rkukura> s3wong: I see now that you said “I do not DISAGREE with that”, which I read as “I do not AGREE with that”
18:38:33 <SumitNaiksatam> banix: yes, that is the current default semantics in the model as well
18:38:51 <s3wong> rkukura: sorry - should have cap-lock the word :-)
18:38:51 <SumitNaiksatam> rkukura: two negatives :-)
18:39:25 <SumitNaiksatam> banix: any concerns with those semantics?
18:39:26 <rkukura> need to take it easy on us native English speakers ;)
18:39:28 <banix> SumitNaiksatam: ok we can disucss more later
18:39:43 <s3wong> rkukura SumitNaiksatam: my crooked English... :-(
18:39:54 <SumitNaiksatam> s3wong rkukura: :-)
18:39:56 <rkukura> I just need to read more carefully
18:39:57 <banix> SumitNaiksatam: not a big concern but in general the app developer expectation may be different
18:40:14 <SumitNaiksatam> banix: ok, any examples?
18:40:30 <banix> SumitNaiksatam: app servers in a tier may not need talking to each other
18:40:56 <SumitNaiksatam> banix: ok
18:41:38 <SumitNaiksatam> so the proposal was to put attributes in the BD, which can define that behavior
18:41:49 <rkukura> banix: As I recall, SGs have an implicit rule allowing all traffic within the subnet. Not sure if we’d be able to use the existing SG API to limit this.
18:42:38 <banix> SumitNaiksatam: i think in the model we may want to have the default as no connectivity but i realize in the mapping driver we may not be able to do that
18:42:46 <banix> rkukura: yes i understand
18:43:36 <SumitNaiksatam> banix: we can probably have attribute in the BD, like “ISOLATED” (probably not a a good name)
18:43:51 <SumitNaiksatam> banix: and its setting can be driven by configuration
18:44:00 <banix> sure let’s discuss at the summit or after the summit
18:44:20 <SumitNaiksatam> banix: if the default BD creation is with this attribute set, then we can support that behavior
18:44:34 <SumitNaiksatam> banix: that way we dont ahve to set it for the ref impl
18:44:37 <SumitNaiksatam> banix: ok
18:44:47 <banix> SumitNaiksatam: ok
18:44:48 <SumitNaiksatam> rkukura: thanks!
18:44:52 <SumitNaiksatam> for the update
18:45:05 <SumitNaiksatam> s3wong: over to you for the service integration
18:45:31 <s3wong> Working on the code now. Couple things I want to raise here, to ensure I am on the right path
18:46:08 <s3wong> (1) since the API is REDIRECT -> [the actual service UUID]. I don't see a need to add anything on the mapping db
18:46:27 <SumitNaiksatam> s3wong: agree (at least for PoC)
18:46:49 <s3wong> so what it amounts to would be writing out the create_policy_action_postcommit
18:46:50 <SumitNaiksatam> s3wong: well let me take that back
18:47:00 <s3wong> SumitNaiksatam: yes?
18:47:11 <SumitNaiksatam> s3wong: how would we undo the action, when we remove the contract?
18:47:40 <SumitNaiksatam> s3wong: never mind, that will still work, becaue the uuid will still be in the contract
18:47:41 <s3wong> SumitNaiksatam: for now? update_firewall to disable it from router
18:47:54 <s3wong> and yes, the UUID would still be in the db
18:47:58 <SumitNaiksatam> s3wong: sorry, you are right, i think it will work
18:48:14 <s3wong> (just not the mapping db)
18:48:56 <s3wong> (2) this is really question for SumitNaiksatam: is update_firewall the right call to enable FW?
18:49:08 <SumitNaiksatam> s3wong: yes
18:49:39 <s3wong> my understanding (via reading FW code yesterday) is, there is one instance of FWaaS per tenant
18:49:59 <SumitNaiksatam> s3wong: one can also enable at the granularity of the rule level (but not needed here)
18:50:05 <s3wong> so it would automatically be enable on all the routers belonging to the tenant?
18:50:07 <SumitNaiksatam> s3wong: yes, one per tenant
18:50:28 <SumitNaiksatam> s3wong: i think default might be that its enabled by default
18:50:58 <SumitNaiksatam> s3wong: but while creating the firewall, i think you can set the admin state to be down
18:51:31 <SumitNaiksatam> s3wong: so although the firewall is there on each router, its not enabled
18:51:41 <s3wong> SumitNaiksatam: OK - so it case the policy_action is removed, I just set the admin state of the FW to down to remove the redirect action?
18:52:25 <rkukura> s3wong: wouldn’t that effect all traffic for the tenant, not just traffic for that one action?
18:52:34 <Louis_> but what of mulitple contracts use that FW instance?
18:53:10 <SumitNaiksatam> s3wong: yes, the iptables rule should get removed
18:53:11 <s3wong> rkukura: yes - unfortunately we need to complete the work of service insertion and steering to change this behavior
18:53:28 <banix> Louis_: i think for now only one contract using the fw is ok
18:53:40 <SumitNaiksatam> Louis_, rkukura: yes as s3wong mentioned, this has much broader scope
18:53:46 <Louis_> agree for the poc
18:53:51 <SumitNaiksatam> the current discussion is in teh context of the PoC
18:53:52 <s3wong> Louis_: for PoC, I think it is fine
18:53:54 <SumitNaiksatam> Louis_: yesh
18:54:09 <mandeep> Louis_: And we need to get started in parallel with the services work that is also still in discussion
18:54:30 <SumitNaiksatam> mandeep: yes
18:54:39 <s3wong> mandeep Louis_: with pretty much the same people in that subteam :-)
18:54:43 <SumitNaiksatam> Louis_: thats a whole other discussion that is happening in parallel
18:55:02 <mandeep> s3wong: :-)
18:55:50 <mandeep> s3wong: At least marun will be happy that it is not a monolithic change
18:56:07 <marun> :)
18:56:12 <SumitNaiksatam> ok moving on
18:56:21 <SumitNaiksatam> #topic CLI and Client
18:56:32 <SumitNaiksatam> Hemanth made greate progress
18:56:35 <SumitNaiksatam> *great
18:56:41 <SumitNaiksatam> he could not attend today
18:56:58 <SumitNaiksatam> banix followed that up with quick progress as well
18:57:00 <s3wong> banix would have to proxy hemanthravi :-)
18:57:15 <SumitNaiksatam> banix: thanks for jumping in yesterday and pushing out the patch yesterday night
18:57:20 <mandeep> +1 That was phenomenal, first pass integration ;-)
18:57:32 <mandeep> +1, thanks banix
18:57:53 <banix> sure
18:58:01 <Louis_> will there be irc meeting next week?
18:58:16 <SumitNaiksatam> Louis_: no meetings next week
18:58:32 <SumitNaiksatam> #announcement no Group policy IRC meeting next week
18:58:48 <SumitNaiksatam> before s3wong demands that it be made official :-P
18:58:53 <SumitNaiksatam> thanks mandeep for the cue!
18:58:56 <Louis_> but there is design session at summit
18:59:00 <SumitNaiksatam> Louis_: yes
18:59:25 <SumitNaiksatam> design summit session discussion is on the agenda
18:59:39 <SumitNaiksatam> but we have not gotten to it
18:59:46 <s3wong> one minute to our next meeting :-)
18:59:56 <SumitNaiksatam> got distracted with some unnecessary discsussions earlier!
19:00:12 <SumitNaiksatam> is ronak here?
19:00:19 <SumitNaiksatam> perhaps not.
19:00:28 <SumitNaiksatam> we probably have to yield to the next meeting
19:00:35 <SumitNaiksatam> so lets call it a wrap
19:00:50 <SumitNaiksatam> thanks all for the awesome work
19:00:57 <SumitNaiksatam> see you at the summit next week
19:01:04 <SumitNaiksatam> safe travels!
19:01:09 <SumitNaiksatam> #endmeeting