19:00:08 <mestery> #startmeeting networking_policy
19:00:08 <hemanthravi> hi
19:00:10 <banix> hi
19:00:12 <openstack> Meeting started Thu Feb 27 19:00:08 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:12 <thinrichs> Hi
19:00:13 <cgoncalves> Howdy!
19:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:15 <openstack> The meeting name has been set to 'networking_policy'
19:00:22 <kevinbenton> hello!
19:00:24 <mestery> Hi folks!
19:00:35 <prasadv> hi
19:00:43 <banix> mestery: hi
19:00:52 <mandeep> mestery: hi
19:01:04 <mestery> #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy Agenda
19:01:05 <marun> hi
19:01:14 <mestery> SumitNaiksatam rkukura: Ping
19:01:25 <SumitNaiksatam> mestery: pong
19:01:31 * mestery realizes rkukura isn't online at the moment.
19:01:36 <SumitNaiksatam> hi all!
19:01:43 <SumitNaiksatam> sorry lost track of time
19:01:49 <s3wong> Hello
19:01:54 <mestery> OK, lets get started, we have a big agenda this week.
19:01:57 <songole> Hi
19:01:59 <mestery> #topic Action Item Review
19:02:10 <mestery> banix: Thanks for pushing the DB code out for review to the shared github!
19:02:44 <banix> mestery: It needs more work...
19:02:49 <mestery> banix: I saw the code is on a branch on the shared github, can you sahre the link here in the meeting?
19:03:00 <banix> and it is under ml2 right now but we can move as needed
19:03:11 <mestery> banix: Thanks!
19:03:28 <mestery> banix: We can talk more about the code in the Data Model section of the meeting as well.
19:03:32 <mestery> #topic Plugin Structure
19:03:45 <mestery> SumitNaiksatam mandeep: Did one of you guys want to lead this section?
19:03:54 <mandeep> SumitNaiksatam: sure
19:04:01 <banix> https://github.com/noironetworks/neutron-group-policy/blob/banix/db/neutron/plugins/ml2/models_gp.py
19:04:19 <mandeep> My understanding from the last meeting was the we agreed that this will be a new plug-in
19:04:40 <mandeep> And that for PoC/Juno we will make it a new core plugin
19:04:53 <mandeep> If we agree with that, we can proceed to the next topoc
19:05:11 <SumitNaiksatam> mandeep: yes, to satisfy the requirements we currently have this will need to be "configured" as a core plugin
19:05:16 <mandeep> (we will revisit is post Juno to see how we can refactor it)
19:05:28 <mandeep> SumitNaiksatam: Yes
19:05:50 <SumitNaiksatam> mandeep: however we can always build this as nicely separated functional blocks
19:05:50 <mestery> Any questions on this from anyone?
19:06:02 <s3wong> SumitNaiksatam: agreed. Let's make it core for now
19:06:03 <mestery> SumitNaiksatam: ^^^^ That right there. :)
19:06:17 <SumitNaiksatam> mandeep: so we can reuse most of what we are doing now if we decide to change course
19:06:31 <mandeep> Yes, that is the plan.
19:06:35 <banix> Sounds good; When we get to coding we will know more about issues that ay be there ...
19:06:43 <SumitNaiksatam> banix: precisely
19:07:05 <SumitNaiksatam> mestery: so i will take a crack at getting this going
19:07:14 <mandeep> mestery: I think we have agreement of this and we get started
19:07:29 <SumitNaiksatam> mandeep: ^^^ :-)
19:07:39 <mestery> #info Group Policy will be implemented as a new core plugin for Juno timeframe.
19:07:45 <mestery> OK, lets move on.
19:07:50 <mestery> #topic Data Model
19:07:59 <SumitNaiksatam> s3wong: sorry did not mean to talk over you, i agree
19:08:01 <mestery> banix: This relates to your code you pushed I think.
19:08:12 <banix> Just before we move on,I am a bit slow today
19:08:19 <banix> more than my usual slow sef
19:08:19 <mestery> #undo
19:08:20 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x2c62b10>
19:08:28 <mestery> banix: No worries. :)
19:09:06 <banix> So this plugin will be supporting the group policy extension. right?
19:09:14 <SumitNaiksatam> banix: yes
19:09:16 <mandeep> banix: yes
19:09:37 <banix> there won't be any easy way for other plugins rouse the implementation in the short term. is that correct?
19:09:50 <SumitNaiksatam> banix: why not?
19:10:12 <SumitNaiksatam> banix: the implementation of the group policy extension has multiple aspects
19:10:26 <mandeep> banix: Existing plugins will be used to "implement" policy using existing API
19:10:27 <hemanthravi> will we have 2 plugins the core plugin and a group-policy plugin (like the service plugins)
19:10:32 <SumitNaiksatam> banix: firstly for the db part we can have a mixin (in line with what we are doing with all other extensions)
19:10:49 <SumitNaiksatam> hemanthravi: no
19:11:14 <hemanthravi> the core plugin will impl the group-policy apis?
19:11:15 <SumitNaiksatam> hemanthravi: for the group policy extensions we will implement the db model in a mixin
19:11:36 <marun> i'm not sure I understand why a core plugin is necessary
19:11:37 <hemanthravi> ok, got it
19:11:44 <SumitNaiksatam> hemanthravi: any other monolithic plugins wishing you implement group policy extensions can also inherit from that
19:11:46 <marun> and what would it be targeting?
19:11:56 <banix> SumitNaiksatam: So you are suggesting the implementation will be such that other plugins could ruse the group policy code
19:12:02 <SumitNaiksatam> you -> to
19:12:18 <SumitNaiksatam> banix: yes, that will be a design goal
19:12:28 <SumitNaiksatam> banix: to the extent possible
19:13:01 <SumitNaiksatam> banix: some specific aspects of policy rendering will obviously be specific to the reference implementation
19:13:20 <marun> is the idea for a core plugin to be like ml2 - a framework for adding support for various implementations?
19:13:52 <SumitNaiksatam> marun: we would need to explore that
19:14:11 <SumitNaiksatam> marun: we could potentially have southbound plugin drivers
19:14:16 <banix> So if we ignore the conflict that the core API may produce with the extension, we could reuse the extension code in another core plugin
19:14:45 <SumitNaiksatam> banix: yes on that latter, but i could not understand the conflict with the core API part
19:14:49 <marun> SumitNaiksatam: I can see a case for that, so long as the implementation is abstracted from the api to allow both core api and extension api to target the same backend
19:15:15 <mandeep> SumitNaiksatam: I agree
19:15:16 <s3wong> marun: I think that would be the goal
19:15:22 <SumitNaiksatam> marun: yeah, we would probably need to iterate a bit to get it right (or validate that its the right approach)
19:15:52 <SumitNaiksatam> marun: gerrit reviews will help :-)
19:16:02 <mestery> +1 to that marun
19:16:03 <marun> SumitNaiksatam: I think it's the right approach regardless.  Designing something that can be used without the api is essential to focused testing.
19:16:10 <SumitNaiksatam> i mean reviewer feedback
19:16:17 <marun> SumitNaiksatam: (most code in the tree fails this smell test)
19:16:29 <SumitNaiksatam> marun: definitely agree
19:16:33 <banix> SumitNaiksatam: core API may imply certain connectivity that may be in conflict with the policies being applied. I thought that was one of the issues. I may have misunderstood
19:16:54 <SumitNaiksatam> banix: its not so much the API
19:17:04 <banix> right
19:17:22 <banix> not the API
19:17:28 <mandeep> banix: That is correct. But if a core plugin decides to implement the policy extensiosn, that plugin will have to resolve the same issues
19:17:31 <SumitNaiksatam> banix: its more the neutron plugin configuration model that would lend itself to more than one point of management of the neutron core resources if we don't have a core plugin
19:17:54 <banix> SumitNaiksatam: makes sense.
19:18:01 <banix> that is what I meant
19:18:10 <mestery> Cool. So I think we're all in agreement here on the new core plugin then?
19:18:12 <SumitNaiksatam> banix: ok cool
19:18:35 <banix> yes, with the goals specified above.
19:18:42 <mestery> banix: great!
19:19:02 <mestery> OK, shall we move on then?
19:19:13 <banix> yes on my end...
19:19:19 <mestery> #topic Data Model
19:19:52 <mestery> OK, we wanted to discuss this from the angle of the original document.
19:20:06 <s3wong> OK
19:20:09 <mestery> I think mandeep had some comments here.
19:20:29 <mandeep> Yes, I has a few questions regarding where we were w.r.t to the contarct model
19:21:10 <mandeep> I understand that the policy currently implemented is essentially a policy on logical links (that is between connectivity groups)
19:21:28 <banix> there are no contracts in the model we agreed on.
19:21:31 <mandeep> That, IMO, loses a lot of the power that comes with a contarct based model
19:21:53 <SumitNaiksatam> mandeep: i think we need to strive to be more declarative
19:21:53 <mandeep> (as discusses in the first part of the model section in the blueprint)
19:22:18 <mestery> Yes: The contract model is in the original design document.
19:22:33 <mandeep> Ideally we want a declarative policy model that allows for late binding and devops type of automations
19:22:38 <SumitNaiksatam> mestery: firstly, i would like to hear from the team here, if we all agree that we want a declarative model
19:22:41 <prasadv> it seems like contract model is more generic than the connectivity model
19:23:02 <mandeep> prasadv: Exactly
19:23:03 <SumitNaiksatam> mestery: the rest of the discussion might flow from that
19:23:04 <s3wong> I remember the model changed when we moved into the src-dst group list model
19:23:06 <mestery> prasadv: Yes, and the document has both models in it as well.
19:23:13 <mestery> SumitNaiksatam: Agreed
19:23:17 <prasadv> sumitNaiksatam: yes
19:23:37 <SumitNaiksatam> banix: do you agree?
19:23:46 <SumitNaiksatam> banix: declarative model goal?
19:23:55 <banix> sure
19:24:06 <mandeep> banix: Great
19:24:08 <SumitNaiksatam> banix: cool
19:24:14 <SumitNaiksatam> so no objections
19:24:44 <songole> I like it better. what are the consequences of the change?
19:24:48 <SumitNaiksatam> so in that context, i think in the current model in the latter part of the document we are confusing the implementation with the tenant facing abstractions
19:24:49 <mandeep> Should a "service provider" be able to define it's policies independent is it's user (which can be determined in a different workflow)
19:25:18 <SumitNaiksatam> i think from a user perspective you only want to declare the following:
19:25:32 <mestery> SumitNaiksatam: That's entirally possible, I struggled with that, and in fact for the Use Cases I have a comment to that effect there :)
19:25:34 <SumitNaiksatam> my endpoint group provides the following contract
19:25:48 <SumitNaiksatam> or, my endpoint group consumes the following contract
19:26:17 <mandeep> songole: The current model couples defining policy from a providers perspective with it's binding to a specific usage
19:26:26 <SumitNaiksatam> now the underlying implementation renders the policy on the link that ties the two endpoint groups together
19:26:41 <SumitNaiksatam> so far make sense to everyone?
19:26:53 <thinrichs> Sorry--missed what the "contract" bit is.  Example?
19:27:04 <banix> SumitNaiksatam: that is reasonable but some may find the other model easier to understand… Mandeep was saying the opposite…
19:27:27 <banix> I thought we agreed that at the end of he day the two models can be converted to each other easily
19:27:47 <SumitNaiksatam> banix: all that i am saying is that we expose the provider/consumer contracts to the end user
19:27:58 <s3wong> SumitNaiksatam: correct. We were operating on a provider/consumer model for a long time in the beginning
19:27:58 <SumitNaiksatam> each contracts is a collection of policies
19:28:00 <mestery> SumitNaiksatam: Yes, that.
19:28:10 <SumitNaiksatam> *contract
19:28:41 <mandeep> At least, from the way SumitNaiksatam explained it, I see the link based rendering "assembly" for a "higher level" contracts and bindings specified independenly
19:28:42 <SumitNaiksatam> the underlying implementation matches the provider contract to the consumer contract
19:28:51 <banix> Sumit, exploring is fine but that will require changes in the object model, API, ...
19:28:52 <thinrichs> So we'd say something like… group A of endpoints allows incoming HTTP requests on port 80?
19:29:08 <SumitNaiksatam> thinrichs: thats correct
19:29:11 <SumitNaiksatam> thinrichs: via a contract
19:29:18 <SumitNaiksatam> banix: changes are not that much
19:29:43 <prasadv> sumitNaiksatam: the binding happens when consumer wants to connect to producer right?
19:29:44 <SumitNaiksatam> banix: will take crack at this and something your way
19:29:50 <SumitNaiksatam> prasadv: yes
19:29:55 <thinrichs> Any way to stop traffic originating on port 80 from group A and ending at port 81 in group B but allow all other traffic?
19:30:12 <mandeep> thinrichs: A contract is logically corelated set of policies that are provided by a service
19:30:31 <mandeep> prasadv: Correct
19:30:31 <thinrichs> mandeep: understood--I was asking if that model is expressive enough to do what we want.
19:30:59 <mandeep> thinrichs: My claim is that the current model is not (and does not even represent that yet)
19:31:39 <thinrichs> mandeep: you're saying that my second example is inexpressible in the version where we attach policy to 2 groups?
19:31:44 <mandeep> And in expressiveness this become a real concern - let us take a use-case:
19:32:19 <mandeep> Say I am a provider of services to multiple tenants which has a set of policies A applied to it
19:32:23 <hemanthravi> thinrichs: that should still work, the contract/policy can define that..allow incoming to 80 from 81
19:32:34 <thinrichs> hemanthravi: agreed.
19:32:35 <mandeep> Let me say that I have a 1000 users of this policy
19:32:38 <hemanthravi> group a provides it...and group b uses that contract
19:33:08 <mandeep> And now, I find a new security issue and want to update my contract from policies A to A'
19:33:50 <mandeep> In a contract base model, I just update my contract and the underlying implementation translates it to 1000 x links
19:33:54 <thinrichs> mandeep: I can see that there are things you might want to say when we attach policy to group A that we can't say if we are forced to attach policy to 2 groups (without copying that policy and applying to all pairs A, A').
19:34:04 <thinrichs> mandeep: understood.
19:34:09 <mandeep> In the current case, the admin will have to know where these policies are used and chnage them one by ine
19:34:24 <hemanthravi> will it also lend to discovery/directory of contracts...
19:34:31 <hemanthravi> that consumers could use
19:34:34 <thinrichs> Perhaps we've identified use cases for both the 1-group and 2-group style of policies.  Didn't we think we could express the 1-group version with the 2-group version?
19:34:47 <mandeep> thinrichs: That is a different - and important - use case that a contarct can express more succiently
19:35:31 <thinrichs> mandeep: Understood.  And I think it's more than just about succinctness.
19:35:47 <mandeep> hemanthravi: Precisely, this now separates the provider workflow from the consumer workflow. And that allows creation of directory/brokers/marketplace
19:35:54 <thinrichs> The 1-group model will apply not only to all the groups that currently exist but also all the groups that will ever be created.
19:36:10 <mandeep> thinrichs: I agree. I was over simplifying it.
19:36:25 <thinrichs> In the 2-group model, we can't apply policy to every group that will ever be created in the future.
19:37:06 <mandeep> thinrichs: That was what I meant by the "late binding" comment that I made earlier.
19:37:07 <banix> mandeep, you may need to specify more information on a contract to differentiate among consumers…. when you do that you are close to the other model
19:37:08 <marun> mandeep: when you say directory/broker/marketplace, i hear 'we're off in the weeds'
19:37:11 <SumitNaiksatam> thinrichs: if we introduce reflexive association for endpoint groups we can possible achieve that
19:37:17 <thinrichs> So it seems we were wrong previously in thinking that the 2-group model is sufficient to encode the 1-group model.
19:37:33 <mandeep> banix: That can be handled in the contacts by using labels (for example)
19:37:51 <SumitNaiksatam> banix: yes that can be encoded in the contracts
19:37:58 <mandeep> marun: Can you be more specific?
19:38:07 <banix> policies across tenants, the consumer/producer model is better
19:38:20 <thinrichs> SumitNaiksatam: there are certainly things we could do to increase the expressiveness model, e.g. make groups a test in the condition of the policy statements, instead of a thing we create via the API.
19:38:37 <banix> otherwise with labels we get back to something close to the other model
19:38:47 <banix> so regardless of the merits of the two models
19:39:05 <banix> the current object model is supposed to work for both
19:39:23 <banix> isn't that what we worked out early on?
19:39:28 <mandeep> banix: No, it allows a provider to provide a "red contarct" and a "green contarct" that any consumer can use later
19:39:33 <SumitNaiksatam> thinrichs: agree (assuming i understood what you just said ;-))
19:39:44 <thinrichs> SumitNaiksatam: :)
19:40:18 <banix> man deep, couldn't that be expressed by defining plicies for a single group?
19:40:21 <mandeep> banix: In general, we can always represent the link based model in this way, so it is a superset that allows for useful operation models
19:40:30 <banix> sorry misspelled
19:40:33 <prasadv> banix: with labels, it seems like the producer is advertising how to access what it is serving and consumer attaches to it right. when consumer epxresses to attach then they are bound like the other model
19:41:13 <mandeep> banix: Except that it can be done in advanced and published. The users can bind later
19:41:14 <banix> prasadv: right
19:41:28 <SumitNaiksatam> to thinrichs's point we can make this model more expressive as we go along
19:41:42 <SumitNaiksatam> the contract allows us the footprint to do that
19:41:44 <mestery> Folks, just a time check: We only have 20 minutes left here.
19:41:44 <prasadv> also labels is one way to do it. based on what is on the rules, it could be other matches
19:41:45 <mandeep> banix: Also, we can update contracts later much more easily
19:42:00 <banix> SO I guess my question is what do we need to add to the model we currently have at the end of the google doc
19:42:04 <mestery> The thing we wanted to get across here was adding contracts into the Object Model.
19:42:15 <SumitNaiksatam> it might be difficult for people to digest everything in the first shot
19:42:15 <mestery> mandeep SumitNaiksatam: Correct me if I've oversimplified there :)
19:42:22 <banix> shall we work that out and discuss again?
19:42:26 <SumitNaiksatam> lets start with the contracts defintion
19:42:29 <SumitNaiksatam> mestery: yeah agree
19:42:45 <mestery> So, I think we're all in agreement on adding contracts into the Object Model right?
19:42:46 <mandeep> mestery: I agree. We wil have to uodate the doc to explain this discussion
19:42:57 <mandeep> mestery: Right
19:43:01 <mestery> I just think we're wandering into the weeds in this meeting a bit :)
19:43:03 <hemanthravi> agreed
19:43:04 <SumitNaiksatam> contract will look very similary to the existing policy, the difference is in the relationships
19:43:18 <SumitNaiksatam> *simlar
19:43:18 <mestery> So, lets put a stake in the ground on contracts being added in.
19:43:24 <mestery> Yes
19:43:25 <SumitNaiksatam> damn invented a new word
19:43:30 <mestery> YHa!
19:43:42 <mandeep> mestery: agreed
19:43:44 <s3wong> mestery: agreed
19:43:57 <mestery> Cool.
19:44:11 <prasadv> mestery, sumitnaiksatam: best to put in document and discuss
19:44:15 <mestery> #info Group Policy Team to look at adding contracts into Object Model.
19:44:18 <mestery> prasadv: Agreed.
19:44:23 <SumitNaiksatam> prasadv: sure, yes
19:44:27 <banix> Can you guys work out the description and update the doc so we can discuss next time
19:44:31 <SumitNaiksatam> prasadv: wanted to discuss here before we did that
19:44:36 <mestery> Who wants to add that into the doc? SumitNaiksatam? mandeep? prasadv?
19:44:37 <mandeep> banix: OK
19:44:39 <SumitNaiksatam> banix: yes definitely
19:44:50 <SumitNaiksatam> mestery: yeah
19:44:51 * mestery waits to hand out an action item
19:44:51 <s3wong> banix: yes, I think doing this in doc is definitely necessary
19:44:58 <mestery> SumitNaiksatam: Sold!
19:44:59 <mestery> ;)_
19:45:11 <mestery> #action SumitNaiksatam to update doc with contracts in object model
19:45:11 <SumitNaiksatam> mestery: of damn, i was just agreeing with you
19:45:15 <mestery> ha!
19:45:16 <mestery> :)
19:45:18 <SumitNaiksatam> *oh
19:45:18 <prasadv> sumitnaiksatam: let me know if you want help there
19:45:25 <mestery> prasadv: Nice, thanks!
19:45:32 <SumitNaiksatam> prasadv: yes, absolutely, lets do it collaboratively
19:45:32 <mestery> OK, 15 minutes left, should we move to the next topic?
19:45:38 <mestery> #undo
19:45:39 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x2d0a710>
19:45:39 <s3wong> we may want to run some use cases against the new model as well
19:45:48 <mestery> #action SumitNaiksatam and prasadv to update document to add contracts to Object Model
19:45:54 <mandeep> s3wong: Yes, that is critical
19:45:55 <mestery> s3wong: Good idea
19:46:02 <mestery> #topic Policy API
19:46:10 <SumitNaiksatam> we will have banix watch over our shoulder ;)
19:46:15 <mestery> SumitNaiksatam: Did you want to cover this?
19:46:18 <s3wong> oh well, with the new model, APIs would need to change
19:46:20 <banix> :)
19:46:31 <SumitNaiksatam> mestery: yeah, i did not touch anything since yesterday
19:46:41 <SumitNaiksatam> mestery: s3wong and i met
19:46:47 <SumitNaiksatam> mestery: we thought we would hold off
19:46:55 <SumitNaiksatam> mestery: so not for lack of effort ;-)
19:47:03 <mestery> Ha! :)
19:47:04 <mestery> Cool.
19:47:11 <s3wong> yeah, no point to submit the API code if we have changes on the horizon
19:47:13 <mestery> Any questions on the API SumitNaiksatam and s3wong published last week?
19:47:31 <SumitNaiksatam> mestery: lets punt this item to the next week
19:47:36 <SumitNaiksatam> mestery: we will make progress
19:47:51 <SumitNaiksatam> mestery: better discussed in the context of today's discussion
19:47:59 <mestery> OK, sounds good. Thanks SumitNaiksatam.
19:48:04 <mandeep> SumitNaiksatam: +1
19:48:05 <mestery> #topic Open Issues/Discussion
19:48:07 <SumitNaiksatam> mestery: oh but one thing, if there are any suggestions on testing, etc, please let us know
19:48:07 <s3wong> and we will need to update the APIs according to the new model, if and when it is agreed upon by everyone
19:48:13 <mestery> s3wong: Yes
19:48:16 <banix> yes we should postpone that discussion
19:48:18 <SumitNaiksatam> testing -> UTs
19:48:35 <banix> s3wong: that's what i meant
19:48:43 <marun> SumitNaiksatam: On the topic of testing, I have a review that demonstrates a retargetable unit test: https://review.openstack.org/#/c/72585/
19:48:44 <s3wong> banix: sure :-)
19:49:01 <SumitNaiksatam> marun: thanks much, will take a look
19:49:15 <marun> SumitNaiksatam: the idea is to write functional tests that can target a plugin's api directly, but can also target a deployed instance using tempest
19:49:28 <cgoncalves> mestery: you did not refresh the group policy meeting page since ~1 hour, yes? :)
19:49:38 <marun> SumitNaiksatam: It offers the promise of only having to write api tests once, have those tests exist in the neutron tree, but be able to target running deployments.
19:49:46 <SumitNaiksatam> marun: ok sure, i will bug (i am slow :-( )
19:49:53 <SumitNaiksatam> * bug you
19:50:01 <marun> SumitNaiksatam: please do :)
19:50:02 <mestery> cgoncalves: Whoops! Actually, I refreshed 10 minutes before the meeting :P
19:50:13 <mestery> Client library was your topic cgoncalves?
19:50:23 <SumitNaiksatam> marun: sure will try to understand and reach out to you accordingly
19:50:43 <mandeep> marun: Good idea
19:50:45 <s3wong> marun: yes, will take a look at your link above
19:51:04 <cgoncalves> mestery: yes. I just wanted to add to this meeting that I've started working on python-neutronclient for group policy
19:51:15 <SumitNaiksatam> cgoncalves: nice
19:51:26 <s3wong> cgoncalves: very good!
19:51:28 <cgoncalves> but it seems much will change on the API side, so better hold it a little longer
19:51:36 <banix> cgoncalves: great
19:51:36 <SumitNaiksatam> cgoncalves: i am guessing you are using the google doc as you are reference?
19:51:40 <cgoncalves> https://github.com/cgoncalves/python-neutronclient/compare/group-policy
19:51:40 <s3wong> cgoncalves: yeah - sorry about that :-)
19:51:44 <SumitNaiksatam> you are -> your
19:51:48 <prasadv> cgoncalves: great
19:52:05 <mestery> Very good cgoncalves!
19:52:08 <mestery> Thanks for your contributions here!
19:52:09 <cgoncalves> SumitNaiksatam: I am, and I did detect diffs between your API code and the doc
19:52:20 <SumitNaiksatam> cgoncalves: there might be more :-)
19:52:28 <SumitNaiksatam> cgoncalves: but great thing to get started
19:52:36 <s3wong> cgoncalves: yeah - for example, action is now a Neutron object
19:52:43 <SumitNaiksatam> cgoncalves: lets all keep in close loop
19:52:48 <SumitNaiksatam> s3wong: right
19:52:49 <s3wong> we just went along when we coded :-)
19:52:59 <cgoncalves> SumitNaiksatam: I've them written down on paper not to forget to re-review them later once you pushed a new version
19:53:23 <SumitNaiksatam> cgoncalves: sweet, thanks for factoring in the changes
19:53:25 <cgoncalves> banix: same for your work on the DB model ;)
19:53:37 <mestery> cgoncalves: I'll keep a slot for client changes each week so we stay on the same page.
19:53:38 <banix> sounds good; thanks
19:53:44 <mandeep> cgoncalves: Is it on the shared github tree?
19:53:57 <cgoncalves> no problem, folks. I'm more than glad to help you. newbie here so bear with me
19:54:06 <s3wong> mandeep: I think cgoncalves provides a link above
19:54:16 <cgoncalves> I did. here it is again: https://github.com/cgoncalves/python-neutronclient/compare/group-policy
19:54:17 <SumitNaiksatam> mandeep: we don't have a repo for neutron client on the shared temp repo
19:54:19 <s3wong> but it isn't on our shared tree
19:54:26 <mandeep> s3wong: cgoncalves: Ooops I missed that!
19:54:31 <SumitNaiksatam> mandeep: we can add that
19:54:35 <s3wong> there isn't a repo in our shared tree yet
19:54:41 <SumitNaiksatam> s3wong: yeah
19:54:45 <mandeep> SumitNaiksatam: OK
19:54:54 <SumitNaiksatam> cgoncalves: should be easy to migrate
19:54:59 <cgoncalves> s3wong, SumitNaiksatam: I can pushed it in to it as long as I have perms
19:55:12 <SumitNaiksatam> cgoncalves: sure, will get back to you
19:55:17 <cgoncalves> that is, if you'd like to
19:55:21 <s3wong> cgoncalves: I believe mandeep is managing that?
19:55:22 <cgoncalves> ok, thanks.
19:55:36 <mandeep> s3wong: Yes, I will set that up
19:55:51 <mestery> #action mandeep to setup neutronclient shared repo
19:55:53 <mestery> Thanks mandeep!
19:56:07 <mestery> OK, 5 minutes left. Anything else for this week?
19:56:22 <cgoncalves> the code is still in its earlies. started yesterday afternoon, so...
19:56:38 <s3wong> mestery: well, PoC may be delayed, hopefully we can still make the J-Summit
19:56:41 <mandeep> cgoncalves: As is all other code ... don't worry
19:56:56 <mestery> s3wong: True dat.
19:56:57 <mandeep> s3wong: We still intent to
19:57:03 <mandeep> s3wong: ;-)
19:57:15 <cgoncalves> mestery: there is yet another topic "services discussion". not sure you want to start it now
19:57:30 <s3wong> cgoncalves: not in three minutes :-)
19:57:33 <mestery> The service itme was to mention we'll cover it in a services meeting next week
19:57:38 <mestery> See the link in the agenda
19:57:42 <mestery> And plan to attend next week
19:57:47 <mestery> So, with that, lets call this meeting.
19:57:49 <cgoncalves> mestery: oh, ok.
19:57:56 <mestery> Thanks folks, progress is good!
19:57:58 <banix> thanks everybody
19:58:02 <mestery> Appreciate all the work from everybody!
19:58:02 <s3wong> thanks!
19:58:03 <mandeep> mestery: Thanks!
19:58:07 <prasadv> thanks
19:58:07 <mestery> #endmeeting