19:00:48 <mestery> #startmeeting networking_policy
19:00:48 <openstack> Meeting started Thu Mar 20 19:00:48 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:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:50 <banix> Hi Kyle and the rest of policy fanatics :)
19:00:51 <openstack> The meeting name has been set to 'networking_policy'
19:00:55 <SumitNaiksatam> mestery, all: hi!
19:01:00 <cgoncalves> hi all
19:01:00 <mestery> banix: policy fanatics, love it! :)
19:01:06 <hemanthravi> hi
19:01:11 <prasadv> hi there
19:01:18 <mestery> #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#March_20.2C_2014 Agenda
19:01:29 * mestery considers renaming the meeting "policy fanatics" in honor of banix's comment.
19:01:38 <rkukura> hi
19:01:40 <banix> :)
19:01:49 <SumitNaiksatam> mestery banix: +1 :-)
19:01:50 <mandeep> hi
19:01:55 <mestery> #topic Action Item Review
19:02:04 <mestery> A very light action item review to start today.
19:02:18 <rms_13_> hello
19:02:19 <mestery> Just a note to continue updating the model with SumitNaiksatam for folks who haven't done so already.
19:02:37 <SumitNaiksatam> mestery: we had numerous discussions
19:02:56 <SumitNaiksatam> mestery: we are making progress
19:03:00 <mestery> SumitNaiksatam: Very good! Was this all updated in your Google doc/ppt?
19:03:05 <mestery> If so, can you #link it here?
19:03:17 <SumitNaiksatam> mestery: yes, and banix has updated as well
19:03:30 <SumitNaiksatam> mestery: #link https://docs.google.com/a/noironetworks.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g1c910cf8b_00
19:03:33 <mestery> Great teamwork!
19:03:46 <mestery> #link https://docs.google.com/a/noironetworks.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g1c910cf8b_00 Policy Model Presentation
19:03:49 <mestery> Thanks SumitNaiksatam!
19:03:53 <mestery> #topic PoC Brainstorm
19:04:10 <mestery> I thought it would be good to spend the bulk of this meeting agreeing on the use case(s) we want the PoC to cover.
19:04:13 <mestery> Does that sound fair to folks?
19:04:19 <SumitNaiksatam> yeah
19:04:23 <SumitNaiksatam> high time :-)
19:04:24 <prasadv> yes
19:04:25 <banix> yes
19:04:34 <mestery> Cool. :)
19:04:36 <s3wong> SumitNaiksatam: sorry for reading the updated doc before the meeting; quickly glanced over, how do I specify qos parameters with the new policy-rule structure?
19:04:50 <SumitNaiksatam> s3wong: still work in progress :-)
19:05:13 <mandeep> The prototype use-case in the blueprint is the 3-tier app, should we focus on that as the PoC use case?
19:05:25 <banix> The suggestion to have a use case for the PoC, or essentially having a demo we work towards realizing by the summit time is very good
19:05:30 <SumitNaiksatam> s3wong: needless to say, feel free to add your comments (you did a lot of work on the actions earlier)
19:05:36 <mestery> mandeep: That seems reasonable to me.
19:05:56 <banix> I think lets step back a bit
19:06:02 <banix> with respect to the Poc
19:06:03 <mandeep> Note tho' the real value of the policy framework shows up when we start adding the lifecycle events - and they need to be flushed out better
19:06:11 <s3wong> SumitNaiksatam: yes, I was defining policy-rule originally - the new structure certainly lacks the extensibility that we targeted at that time
19:06:42 <banix> we want to show case the capability of the policy framework, so as such we have to demonstrate why using such a policy makes life easier or better
19:06:50 <SumitNaiksatam> s3wong: ok lets discuss that (as follow up perhaps?)
19:06:58 <SumitNaiksatam> banix: +1
19:07:00 <s3wong> don't get me wrong, a good start nevertheless :-)
19:07:00 <mestery> banix: That's ag ood point, aligns with what mandeep is indicating as well.
19:07:39 <SumitNaiksatam> banix: please go on
19:07:44 <banix> the three tier case is good case but I think the punch line would be how we end up realizing it in an application centric way
19:07:45 <SumitNaiksatam> banix: you have some thoughts?
19:07:58 <SumitNaiksatam> banix: absolutely
19:07:59 <mestery> Agreed banix.
19:08:21 <SumitNaiksatam> so far i think we have been thinking about how we can realize the legacy model using this new model
19:08:22 <banix> SO I am saying the power should come out as how easy it is for end users/apps define and deploy these policies
19:08:44 <mestery> I think both banix and SumitNaiksatam are bringing up good points here.
19:09:15 <banix> SumitNaiksatam: Agree, which is necessary but we need to go beyond that
19:09:19 <mandeep> banix: Yes. Clear sepration on app/infra concerns - and automatic deduction of specific low level details
19:09:34 <SumitNaiksatam> banix: just typing that its necessary but not sufficient
19:09:49 * SumitNaiksatam thinks banix can mind read :-)
19:09:57 <banix> man deep, SumitNaiksatam: exactly
19:09:59 <hemanthravi> mandeep: by lifecycle events, do you mean adding endpoints into a group and having the policy apply auto
19:10:41 <mandeep> hemanthravi: That, and other more dynamic ganges -like new consumers, new infra policy like "inspect all external traffic by IDS", etc
19:12:11 <mestery> OK, so circling back here, do we need to go beyond 3-tier app for the PoC?
19:12:13 <mandeep> In particular, with initial app creation, then updating the app policy, updating the infra policy, updating connectivity issues (like subnets, routes, service insertion, etc)
19:12:17 <s3wong> mandeep: that would be more a UI functions, our Neutron APIs would still be 'redirect' to service that happens to be IDS
19:12:42 <prasadv> are we saying that we will demo 3 tier model and then show agility of using this for dynamic changes  will show the power of group policy?
19:12:45 <s3wong> mestery: I would think if we can do end to end 3-tier app for PoC, that would already be very good
19:12:45 <banix> I think if we demonstrate how easily we can deploy a three tier app with a simple heat template with little reference to the nuts and bolts of "networking"" being used that would be a good start. What do you think? There is a few neat things we can build on top of that but is this a good start? other suggestions?
19:13:07 <mandeep> s3wong: In the model, you want to do that without impacting the provider contract since that is an app constraint orthogonal to the app concerns
19:13:13 <s3wong> that is, from Horizon -> Heat template -> Neutron...etc
19:13:33 <mestery> s3wong: Fair point, just want to make sure everyone is in agreement on the 3-tier app being enough.
19:13:51 <SumitNaiksatam> s3wong: playing devil's advocate - you can realize the same three tier app using legacy model
19:14:07 <mandeep> banix: Sounds interesting, but adds heat to PoC [tho' it might be worth it]
19:14:22 <SumitNaiksatam> i think its good to add heat to the PoC
19:14:29 <SumitNaiksatam> but we have to be careful here
19:14:30 <mestery> +1 to adding heat
19:14:39 <SumitNaiksatam> we need to show clear separation of concerns
19:14:41 <mestery> It stresses the value of the abstractions we have come up with
19:14:41 <s3wong> SumitNaiksatam: absolutely. Reference to banix 's presentation back in the I-Summit; instead of using 20 Neutron APIs, we are now using 5
19:14:57 <mandeep> My concern was not about it being good, but about resources ;-)
19:15:10 <mestery> mandeep: :)
19:15:16 <SumitNaiksatam> people often tend to ask as to whether the policy model is merely orchestration, that can be subsumed in heat
19:15:24 <SumitNaiksatam> i don't agree with that
19:15:29 <SumitNaiksatam> but if we drive this from heat
19:15:36 <mandeep> Yes, and PoC can answer that question
19:15:39 <s3wong> SumitNaiksatam: and that most of the construct abstracts out the port/address level knowledge
19:15:40 <SumitNaiksatam> we might loose those people
19:15:47 <banix> s3wong: that's what I was going to add, and in that presentation towards the end there are a couple of things that go beyond simple 3-tier
19:16:03 <banix> SumitNaiksatam: that is a very good point that point was raised in the summit
19:16:07 <prasadv> sumitnaiksatam: There is a little bit of overlap with heat though
19:16:07 <mandeep> banix: Can you send a link to your presentation?
19:16:20 <prasadv> we need to be clear as to the boundaries
19:16:22 <banix> sure. let me dig it out.
19:16:42 <SumitNaiksatam> prasadv: i agree, and we need to have a crisp understanding of this, which we will, but difficult to convey to others who see this for the first time
19:16:46 <prasadv> and yes I like having heat in it answer questions
19:17:01 <mandeep> prasadv: Yes, that is why we need to be crisp as SumitNaiksatam identified
19:17:03 <prasadv> particularly dynamic changes and instantiation
19:17:33 <SumitNaiksatam> i would dare to suggest, lets try to bring out the value in this PoC without using Heat
19:17:40 <SumitNaiksatam> so as not to confuse the audience
19:17:46 <banix> #link https://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/presentation/network-abstraction-at-different-layers-of-the-stack
19:17:46 <SumitNaiksatam> just a thought
19:17:50 <prasadv> +1
19:17:59 <SumitNaiksatam> besides, per mandeep i am not sure we have the resources either
19:18:04 <banix> will find the pdf; watching the video may be painful :)
19:18:19 <s3wong> SumitNaiksatam: I think using application template as a frontend is one of the major advantages of group-policy, no?
19:18:28 <mandeep> prasadv: Exactly. It is in dynamic behavior that policy really differentiates over heat type of ochestration
19:18:29 <SumitNaiksatam> so it might just be infeasible from a resource perspective to do it (in which case we don't have a choice)
19:18:38 <mandeep> banix: thanks
19:18:45 <SumitNaiksatam> s3wong: not disagreeing with that
19:19:21 <SumitNaiksatam> s3wong:  but then the policy abstractions are probably lost on the people
19:19:34 <mestery> It's a fine balance SumitNaiksatam, I agree.
19:19:40 <SumitNaiksatam> mestery: yeah
19:19:44 <banix> SumitNaiksatam: what do you suggest that we show? Let's say we do not use heat, you are suggesting something like a 3-tier app or something different?
19:20:05 <SumitNaiksatam> okay, so i am just thinking loud
19:20:12 <s3wong> SumitNaiksatam: if not using Heat, we have to pick something else to emphasize (more visually) for people to see the advantage of group-policy
19:20:15 <banix> mastery, Sumit: yeah I agree, we need be careful of that concern
19:20:25 <rms_13_> Cant we do primary demo WITHOUT heat to clarify policy concept; and than add heat in a last few minute doing same stuff as a quick video?
19:20:28 <banix> that issue will come up as it did during the design session
19:20:44 <SumitNaiksatam> rms_13_: yes, sure
19:21:02 <s3wong> rms_13_: interesting suggestion
19:21:04 <SumitNaiksatam> s3wong: visually can be achieved with horizon integration, no?
19:21:37 <SumitNaiksatam> ok, i also don't want us to miss the main point of this discussion, which is the use case
19:21:37 <s3wong> SumitNaiksatam: perhaps visually is a poor way to say it - to demo the ease of operation via group-policy
19:21:52 <banix> yes lets focus on the use case
19:21:55 <prasadv> sumitnaiksatam: we would need a policy builder in UO right?
19:21:59 <prasadv> *UI
19:22:02 <SumitNaiksatam> we can decide on heat or not later
19:22:29 <SumitNaiksatam> prasadv: well, at least some representation
19:22:38 <SumitNaiksatam> so coming back to the use case
19:22:40 <mandeep> We do have a PoC doc, should this discussion move to that doc?
19:22:50 <banix> SumitNaiksatam: Please go ahead; Do you have any particular use case in mind
19:23:12 <SumitNaiksatam> mandeep: yeah we can put thoughts on the doc
19:23:38 <s3wong> SumitNaiksatam: use case?
19:23:39 <rms_13_> 3-tier app is something which people would relate to very easily as a use case. Solving that end to end + "just mentioning" few more should suffice
19:23:59 <SumitNaiksatam> s3wong banix: it was more of a question
19:24:12 <SumitNaiksatam> i think 3-tier is good, but the same can be shown with a single tier as well
19:24:40 <s3wong> SumitNaiksatam: please elaborate
19:24:55 <banix> so let's develop that single tier use case a bit further
19:25:03 <SumitNaiksatam> s3wong:  i mean the benefits we are trying to show for the policy model
19:25:30 <SumitNaiksatam> s3wong: multiple tiers would be an extension of that
19:26:02 <SumitNaiksatam> but really, the benefit should be evident even with a single tier
19:26:13 <SumitNaiksatam> i am not saying that we will not show 3-tier
19:26:36 <SumitNaiksatam> but for our own understanding, i think we need to flesh out a single tier
19:26:42 <SumitNaiksatam> workflow, etc
19:26:47 <banix> let's see what we have in that single tier, so we can decide ...
19:27:04 <s3wong> SumitNaiksatam banix: for those who are interested, the ODL project google doc has TONS of use cases
19:27:05 <SumitNaiksatam> banix: go ahead
19:27:12 <s3wong> #link https://docs.google.com/document/d/12Z1JHhCFS6ta-ux3UdUbFaEPzAig_3Xgnbj29Nejfug/edit
19:27:17 <SumitNaiksatam> s3wong: thanks
19:27:19 <prasadv> i think showing single tier with redirection and allow/deny would be good to show?
19:27:20 * mestery has walked through those use cases far too many times. :P
19:27:27 <banix> then we can see if we need to build on it to make it more interesting (assuming we have time to do that)
19:27:56 <banix> Sumit: That was more of a suggestion to you :)
19:27:56 <SumitNaiksatam> mestery: i think stands out to you from venturing there?
19:28:09 <SumitNaiksatam> *anything
19:28:10 <prasadv> in a way that is 2 tier - service tier and app tier
19:28:24 <banix> prasadv: that makse more sense
19:28:40 <mestery> SumitNaiksatam: I think we should try to keep it simple at first to prove the points as you say, then see how far we can take it. Sound good?
19:28:41 <banix> I think that is probably what Sumit and others mean by a single tier
19:28:55 <mandeep> agreed
19:28:55 <banix> mestery: yes
19:28:57 <prasadv> so internal users go through simpler service tier and external users go through more secure tier?
19:29:10 <mestery> Agreed banix
19:29:10 <mandeep> prasadv: yes
19:29:23 <prasadv> we show case tags, classifers etc
19:29:28 <s3wong> prasadv: that probably already requires labels, right?
19:29:40 <prasadv> not tags but labels
19:29:41 <banix> let's not get into details of how we do it
19:29:48 <mestery> Yes, the doc can have details right?
19:29:54 <nbouthors_> that looks like a data center access use case
19:30:16 <banix> right, let's focus on what we want to demo such that we showcase the power of policies. makes sense?
19:30:29 <mandeep> mestery: banix: Yes, let move this to doc, IRC is probably not the best way to work out the PoC details
19:30:39 <prasadv> nbouthers_: it is application deployment use case
19:30:45 <mestery> #action Team to flesh out PoC details in doc
19:30:47 <banix> then we go back to work as how we can realize that demo
19:30:52 <mestery> mandeep: Do you have the link for that doc we can post here?
19:31:10 <mandeep> mestery: let me get it.
19:31:14 <mestery> Thanks mandeep!
19:31:16 <s3wong> https://docs.google.com/a/midokura.com/document/d/14UyvBkptmrxB9FsWEP8PEGv9kLqTQbsmlRxnqeF9Be8/edit
19:31:20 <s3wong> here it is :-)
19:31:41 <s3wong> the great PoC doc :-)
19:31:46 <mandeep> #link https://docs.google.com/a/noironetworks.com/document/d/14UyvBkptmrxB9FsWEP8PEGv9kLqTQbsmlRxnqeF9Be8/edit
19:31:47 <SumitNaiksatam> s3wong: thanks :-)
19:32:01 <banix> s3wong: thanks
19:32:01 <s3wong> with about 5 lines of text :-)
19:32:03 <mestery> Thanks s3wong and mandeep!
19:32:05 <mestery> Ha!
19:32:05 <mestery> :)
19:32:23 <SumitNaiksatam> if you have to make a start somewhere :-)
19:32:59 <s3wong> SumitNaiksatam: as you can see we had no idea what we wanted to demo :-)
19:33:09 <banix> yeah, so prasadv: can you elaborate as the use case you mentioned
19:33:18 <mestery> s3wong: :)
19:33:26 <banix> s/as/about
19:33:26 <SumitNaiksatam> s3wong: i guess its called evolution :-)
19:33:36 <SumitNaiksatam> organic evolution
19:33:49 <prasadv> banix: I was thinking we can deploy  a app tier say lamp stack with redirection to service layer
19:34:07 <prasadv> say a firewall
19:34:23 <banix> prasadv: thanks
19:35:02 <prasadv> just thinking aloud around single tier showcase
19:35:06 <cgoncalves> prasadv: or firewall+lb? :-)
19:35:23 <s3wong> thinking outloud for PoC timeframe - API we can do whatever we want, so the limiting factor is OVS
19:35:34 <prasadv> cgoncalves: yes, some appliance(s)
19:35:44 <s3wong> prasadv 's suggestion seems to be feasible for OVS support POV
19:35:56 <banix> I think with a use case like the above we may run into ta question like: couldn't you do that today, using fwaas for example
19:36:25 <s3wong> banix: true, it is also not really "application" perspective...
19:37:25 <mandeep> banix: You could. The claim is that it is a higher level description on intent that may be realized using existing capabilities (or we can create new ones)
19:37:26 <prasadv> i am hoping it to be more than Fwaas with connectivity groups, Allow/deny
19:38:01 <banix> mandeep: yes, exactly, somehow we have to showcase that aspect of what we are doing
19:38:18 <mandeep> banix: Agreed
19:38:46 <banix> Using Heat is a convincing option (again assuming we have time to get there); if not what other options do we have
19:39:04 <banix> just asking the question
19:39:29 <s3wong> use case should be from user perspective. So it should start with "I am an app owner, I want to deploy an app...
19:39:39 <SumitNaiksatam> i think of to consider the "app developer" role
19:39:45 <SumitNaiksatam> * i think we have to
19:39:46 <prasadv> s3wong:  I agree
19:39:47 <banix> prasadv: I think a single firewall would be fine, the point that we need to demonstrate is how we get to deploy it
19:39:53 <SumitNaiksatam> s3wong: exactly
19:40:11 <SumitNaiksatam> lets not get into the capabilities of services
19:40:12 <banix> s3wong: agrees
19:40:20 <mandeep> SumitNaiksatam: Agreed
19:40:20 <SumitNaiksatam> i think that is bit orthogonal
19:40:39 <SumitNaiksatam> mandeep earlier mentioned about lifecycle events
19:40:40 <banix> yes, the service itself not that important
19:40:52 <banix> any service would do; even one i think is fine
19:40:56 <SumitNaiksatam> i think that is tied into the "app developer's" role
19:41:14 <SumitNaiksatam> in the sense that, what he has to do today with the legacy abstractions
19:41:24 <SumitNaiksatam> versus what he would have to do with the new policy abstractions
19:41:25 <banix> can you state the lifecyle events again
19:41:42 <SumitNaiksatam> i will conveniently punt that to mandeep :-P
19:41:46 <banix> or I can go back above and read what you had said :)
19:42:05 <s3wong> SumitNaiksatam: agree - very simply, if I add a VM into my application pool, I need to connect vport to network, update security group...etc
19:42:08 <mandeep> 1. Create (where the intent is expressed and low level automation is done)
19:42:19 <SumitNaiksatam> s3wong: yes, nicely put
19:42:23 <rms_13_> Just thinking loud here: would it make sense to create a video of achieving our use-case by today's model. Than explaining and demoing ease/differentiation policy provides for doing same thing?
19:42:25 <s3wong> now you can simply do it via automatically adding the new VM vport in a EPG
19:42:29 <mandeep> 2. Update app behavior - Say updates to contarcts
19:42:38 <mandeep> 3. Updates to infrastructure
19:42:39 <SumitNaiksatam> rms_13_: good point, we should
19:42:48 <mandeep> 4. Dynamic binding
19:42:59 <banix> rms_13_: sure but lets see what use case we pick first
19:43:09 <mestery> +1 to that rms_13_.
19:43:22 <mandeep> 5. Infrastructure based modulation (say QoS or path selection or service selection)
19:43:50 <SumitNaiksatam> mandeep: perhaps you can add to the doc, i think we all need to be on the same on this basic understanding
19:44:20 <mandeep> Yes, I will do that
19:44:28 <banix> So I had this simple example, would that be a simple case of what you are describing' this example:
19:44:38 <SumitNaiksatam> currently we don't have a "app developer" role in neutron
19:44:41 <SumitNaiksatam> mandeep: thanks
19:44:52 <SumitNaiksatam> banix: go ahead
19:45:37 <prasadv> maybe we should have an action item to have couple of proposals presented by individuals or groups next week
19:45:49 * s3wong waiting on banix... :-)
19:45:56 <banix> You specify a policy where you employ a loadbalancer between two groups (a provider and a consumer in new model); then adding a new endpoint to the group will automatically lead to the loadbalancer to adding it to its pool
19:46:04 * banix is slow
19:46:28 * SumitNaiksatam knew banix was coming up with something deep
19:46:37 <s3wong> banix: that seems to require us to add members to the pool for an LBaaS instance
19:47:04 <s3wong> which isn't one of our defined actions at this point...
19:47:23 <SumitNaiksatam> s3wong: loadbalancer config will be required but thats orthogonal
19:47:33 <banix> s3wong: yes but the point is you don't do it (at the user level), it happens because of the policy being there
19:47:52 <SumitNaiksatam> banix: i think you will still required the LB config
19:47:57 <SumitNaiksatam> *require
19:48:05 <s3wong> banix: but how is it represented by what we have in group-policy today - that is, how do I set up such contract?
19:48:07 <SumitNaiksatam> banix: but there is still value here
19:48:44 <banix> yes to all the above but that is the type of thing lifecycle events man deep was explaining would do?
19:49:20 <SumitNaiksatam> banix: true, perhaps not use the loadbalancer
19:49:50 <SumitNaiksatam> banix: just say, add another VM to the end point group?
19:49:59 <banix> exactly
19:50:07 <SumitNaiksatam> banix: or another end point, that is
19:50:20 <banix> that's what I said or thought i was saying
19:50:25 <s3wong> SumitNaiksatam: now that makes sense, as a new endpoint to EPG will automatically get the new endpoint to inherit all the policy atrributes
19:50:51 <banix> "then adding a new endpoint to the group "
19:50:59 <mandeep> banix: I think we need to get this all in doc, there are too many issues here to get into on the IRC (I am an IRC newbie)
19:51:15 <banix> "will automatically lead to"
19:51:17 <banix> yes
19:51:33 <SumitNaiksatam> mandeep: yeah, difficult to do this without diagrams :-)
19:51:42 <s3wong> or whiteboard :-)
19:51:55 <banix> so the question is not this particular example but is this what we want to aim for
19:52:02 <banix> this type of capability, i mean
19:52:25 <mestery> OK, so at this point, should we just focus on getting this into the doc?
19:52:30 <SumitNaiksatam> yeah, i think banix is validating the understanding of "lifecycle events"
19:52:32 <mestery> It seems we have only 8 minutes left anyways. :)
19:52:35 <openstack-meetin> I have writeup of  mucb of this tbat Im drafting for ODL GBP and ONF NBI ( how gbp info model achieves a bunch ofuse cases)
19:52:41 <s3wong> banix: yes, this simple use case should demostrate ease of operation of GBP
19:52:49 <prasadv> mestery: can we move this meeting up an hour?
19:52:52 <mandeep> banix: Yes, we need to aim to show value as you identified, but I think we are getting mixed up with the scope issues (say LBaaS is included in POC or not)
19:53:05 <prasadv> for people who are making trek to noiro for ODL group policy meeting
19:53:20 <mestery> prasadv: OK, let me look into that.
19:53:29 <mestery> #action mestery to look at moving meeting up one hour.
19:53:30 <s3wong> Hmm... what is openstack-meetin talking about? I am a bit lost
19:53:38 <mestery> s3wong: Same here.
19:54:03 <prasadv> mestery:thanks
19:54:11 <SumitNaiksatam> openstack-meetin: can you identify yourself? ;-P
19:54:35 <s3wong> prasadv: amazing, I am OK with the time - being in the ODL meeting couple minutes late isn't a big deal - as webex setup typically takes that much time anyway :-)
19:54:46 <openstack-meetin> Sorry dave lenrow, new irc client
19:55:01 <banix> Openstack-meetin: I am what controls everything from behind the scene: I am openstack!
19:55:05 <banix> just kidding
19:55:23 <mestery> Ha! I like the nic openstack-meetin ;)
19:55:27 <mestery> OK, 5 minutes left folks.
19:55:29 <banix> Almost out of time
19:55:31 <mestery> Should we move to the document at this point?
19:55:38 <mestery> #topic Closing Thoughts
19:55:39 <s3wong> mestery: absolutely
19:55:47 <mestery> OK, cool.
19:55:53 <banix> yes but we need to close on this rather quickly. right?
19:56:29 <SumitNaiksatam> dlenrow: welcome!
19:56:37 <s3wong> I will work with SumitNaiksatam on policy-rule definition refinement
19:56:44 <SumitNaiksatam> banix: agree
19:56:46 <dlenrow> I want to get doc aligned to neutron GBP POC work
19:56:58 <mestery> dlenrow: That's a good goal!
19:57:10 <s3wong> dlenrow: which doc?
19:57:22 <banix> dlenrow: any loiters will be helpful
19:57:26 <banix> pointers
19:57:47 <SumitNaiksatam> dlenrow: which doc are you referring to?
19:57:59 <dlenrow> Doc Im drafting for ODL GBP (next call)
19:58:05 <mestery> :)
19:58:15 <mandeep> dlenrow: Got it
19:58:34 * s3wong has no idea there is another doc for ODL project, but whatever :-)
19:58:44 <mestery> s3wong: Docs for everyone! :P
19:58:51 <mestery> OK, lets call this meeting now.
19:59:01 <mestery> Lets get the PoC use case doc finished for next week's meeting if we can.
19:59:02 <mestery> Sound good?
19:59:10 <banix> let's work on the poc use case through email
19:59:11 <SumitNaiksatam> yeah
19:59:11 <s3wong> mestery: as you know, we started off with a doc which now points to another doc :-)
19:59:23 <mestery> s3wong: Doc abstraction :)
19:59:25 <SumitNaiksatam> s3wong: lol!
19:59:27 <mestery> OK, thanks folks!
19:59:29 <mestery> #endmeeting