18:01:50 <SumitNaiksatam> #startmeeting networking_policy
18:01:51 <openstack> Meeting started Thu Jul 10 18:01:50 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:51 <mandeep__> SumitNaiksatam: Hi
18:01:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:54 <openstack> The meeting name has been set to 'networking_policy'
18:02:18 <SumitNaiksatam> #info agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#July_10th.2C_2014
18:02:33 <SumitNaiksatam> #announcements Juno specification submission deadline: July 10th, specification approval deadline: july 17th
18:03:43 <rkukura> hi - sorry I’m late
18:04:07 <mandeep__> rkukura: Hi
18:04:15 <SumitNaiksatam> i believe we got a few more related specs in to beat the deadline
18:04:20 <SumitNaiksatam> rkukura: hi
18:04:46 <SumitNaiksatam> #topic Patches in review
18:04:47 <s3wong> SumitNaiksatam: Oh? I thought our spec has already been approved?
18:04:53 <SumitNaiksatam> #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches
18:05:03 <SumitNaiksatam> s3wong: i meant a few other specs
18:05:24 <SumitNaiksatam> s3wong: some vendor specs, and kevinbenton posted a spec for the API intercept as well
18:05:33 <s3wong> OK
18:05:34 <SumitNaiksatam> we will discuss those later in the agenda
18:05:35 <mandeep__> s3wong: Specs for InterceptAPI, ODL driver, and vendor drivers
18:05:50 <SumitNaiksatam> just wanted to callout earlier that if something more is being planned, it should land today
18:06:18 <SumitNaiksatam> i moved the links to the patches to a different page, and i am in the process of organizing the content
18:06:51 <SumitNaiksatam> so that its easier for the people who are reviewing to understand what each series is doing and what are the dependencies
18:07:18 <SumitNaiksatam> feel free to update that page once i have the content in there
18:07:24 <SumitNaiksatam> i mean more content
18:07:37 <SumitNaiksatam> #topic Resource Model/API/DB/Plugin Update
18:08:01 <SumitNaiksatam> got some more reviews comments before the july4th break, and have responded to all of them
18:08:40 <SumitNaiksatam> no negative comments on the first series, except the -2 from markmcclain which was for the missing driver patches
18:08:54 <mandeep__> SumitNaiksatam: Thanks for that. That now gives us enough of a model to base the new GBP drivers on
18:08:55 <SumitNaiksatam> the driver patches have landed, so we expect markmcclain will remove the -2
18:09:03 <SumitNaiksatam> mandeep__: sure
18:09:04 <rkukura> I spoke with markmcclain about this a little while ago
18:09:10 <SumitNaiksatam> rkukura: great, thanks
18:09:38 <rkukura> He does feel we should get gpm-rmd-1 out of WIP state before we start merging the series
18:10:15 <rkukura> He’d also like to see some sort of tempest-like functional test that verifies datapath connectivity.
18:10:21 <SumitNaiksatam> rkukura: okay
18:10:57 <SumitNaiksatam> rkukura: okay lets get back to the first part, when we discuss your mapping driver update
18:11:07 <markmcclain> yeah a working driver and some kind of testing ensures we're not merging broken code
18:11:17 <SumitNaiksatam> markmcclain: agree
18:11:25 <rkukura> And we do need the DB migrations in each patch that adds/modifies DB model clases
18:11:35 <markmcclain> rkukura: +1 that is req
18:11:44 <SumitNaiksatam> rkukura: yes, db migration is pending
18:11:56 <SumitNaiksatam> rkukura markmcclain: however that is mechanical
18:12:08 <SumitNaiksatam> i will be happy to add it right away, if we are close to that stage
18:12:45 <SumitNaiksatam> if we agree that we are past the initial churn on the DB model, i am happy to add the db migration, right away
18:12:52 <SumitNaiksatam> do we agree?
18:12:52 <rkukura> I’d really like to get any remaining reviewer input into the first few patches, but am concerned the -2 is hindering that
18:13:02 <SumitNaiksatam> rkukura: i agree
18:13:48 <rkukura> I can get an updated gpm-rmd-1 patch out by Monday, maybe sooner, but also need to review a bunch of specs
18:14:12 <SumitNaiksatam> okay, so i think there is silent agreement that the DB model on the first series (EP, EPG, L2/3 Policy) is stable
18:14:19 <SumitNaiksatam> so i will add the migration script
18:14:38 <SumitNaiksatam> #action SumitNaiksatam to add DB migration script to first series of GP resources
18:14:50 <rkukura> Does anyone want to volunteer to write a functional test that could later become a tempest test (in K, after API compatability is required)?
18:15:10 <mandeep__> SumitNaiksatam: For downstream drivers, we have to assume that the model is reasonably stable to started on that development.
18:15:20 <SumitNaiksatam> mandeep__: okay
18:15:36 <SumitNaiksatam> rkukura: i believe rudra rugge wanted to do that
18:15:43 <SumitNaiksatam> rkukura: we can ping him
18:16:03 <mandeep__> SumitNaiksatam: Yes, Rudra had wanted to tackle that during the summit
18:16:18 <rkukura> This may be needed before anything can merge, so we need some commitment
18:16:30 <SumitNaiksatam> rkukura: i agree with the approach though, i think we can add the functional test right away, and that will ensure sanity of the patches
18:16:44 <rkukura> It should be doable based on the current gmp-rmd-1 patch and its dependencies.
18:17:06 <SumitNaiksatam> markmcclain: does that sound good? ^^^ (add funcational test to neutron for testing the sanity of the first series)?
18:17:31 <SumitNaiksatam> *functional
18:17:44 * markmcclain catches up
18:18:35 <LouisF> SumitNaiksatam: did you add that diagram on the mapping driver
18:18:45 <mandeep__> SumitNaiksatam: That makes sense if we all agree that the model looks good and that we are waiting for tests to validate that we have end-to-end correctness. It would not make sense if there was any disagreement on the model. So I assume that we are all agreeing on the model.
18:19:02 <markmcclain> SumitNaiksatam: looks good
18:19:12 <SumitNaiksatam> mandeep__: i think we have agreement on that right, from the spec?
18:19:14 <SumitNaiksatam> markmcclain: thanks
18:19:23 <SumitNaiksatam> LouisF: sorry, i dont have that yet, i will add
18:19:33 <mandeep__> SumitNaiksatam: Yes, you are right.
18:19:40 <LouisF> thx
18:20:05 <SumitNaiksatam> #action SumitNaiksatam to add diagram fo explain the different functional blocks in the GP stack
18:20:24 <rkukura> forgot to mention something regarding gpm-rmd-1
18:20:29 <SumitNaiksatam> #action GP team to add functional test(s) to neutron to aid in merging of the first series of patches
18:20:41 <SumitNaiksatam> rkukura: can you hold that, till we change the topic?
18:20:45 <rkukura> markmcclain and I discussed the various approaches for invoking other plugins
18:20:51 <SumitNaiksatam> rkukura: separate agenda item for mapping driver
18:20:55 <rkukura> ok
18:21:19 <SumitNaiksatam> in fact i will change that right away, if nothing else to discuss on the API/Resource model
18:22:25 <SumitNaiksatam> #agreed Fair level of consensus (or no immediate dissents) on the API/DB model for GP-API/EB/PLG-1 patches, such that functional tests can be attempted using the mapping driver available
18:22:46 <SumitNaiksatam> #topic Mapping Model/Driver Update
18:22:52 <SumitNaiksatam> rkukura: sorry, go ahead
18:23:07 <rkukura> ok
18:23:49 <rkukura> so markmcclain also has concerns similar to mine regarding using python-neutronclient for invoking the other plugins
18:24:12 <SumitNaiksatam> rkukura: okay, i had those earlier as well
18:24:32 <rkukura> in particular, the fact that invocation chains could crisscross between different neutron-server replicas could be a problem
18:24:33 * regXboi running late agan :(
18:24:42 <s3wong> rkukura: OK - are we thinking of NOT using python-neutronclient now?
18:24:53 <rkukura> and the UT issues I had hit are real
18:25:44 <mandeep__> rkukura: Yes, we had the same concern earlier, but my understanding was that armax had specific feedback to use python-neutronclient. Did you get an opportunity to discuss with him?
18:25:48 <rkukura> markmcclain described his ongoing work on refactoring the WSGI->Controller-plugin front-end
18:26:45 <SumitNaiksatam> rkukura markmcclain: i believe that work is not planned for Juno right?
18:26:47 <rkukura> It sounds like markmcclain’s refactoring will provide an ideal interface for our long-term use
18:26:57 <rkukura> He is working to get this in for juno
18:27:05 <rkukura> But we cannot depend on it merging first
18:27:10 <SumitNaiksatam> rkukura: agree
18:27:15 <mandeep__> rkukura: agreed
18:27:23 <armax> I am getting up to speed with the latest developement
18:27:37 <SumitNaiksatam> rkukura: in the interim, i think direct calls, provide a reasonable path forward
18:27:39 <armax> I know that rkukura and markmcclain chatted about this but I don’t know the specifics
18:27:40 <rkukura> So we agreed sticking with the current approach is best for the interim
18:28:01 <armax> I’ll touch base with people offline
18:28:02 <SumitNaiksatam> rkukura: thats seems very logical and reasonable to me
18:28:13 <mandeep__> rkukura: Can you review it with armax as well?
18:28:39 <rkukura> markmcclain told me he is willing to disucss this with armax if needed - we all agree its not ideal long term due to possible divergence between the real Controller and our version, but it should suffice
18:28:50 <SumitNaiksatam> rkukura: i believe with that, the gp-rmd-1 patch can come out of WIP right away?
18:29:09 <mandeep__> rkukura: OK
18:29:25 <s3wong> rkukura: so with the current approach, we are still going with python-neutronclient?
18:29:31 <rkukura> I need to add code to handle updates, keep track of whether mapped resources are owned, and cleanup owned resources when GP resources are deletted
18:29:39 <SumitNaiksatam> rkukura: okay
18:29:51 <rkukura> this will all follow patterns already in the implciit_policy driver
18:29:59 <SumitNaiksatam> s3wong: in our current approach we dont use the python-neutronclient
18:30:25 <SumitNaiksatam> s3wong: as deteremined by rkukura, and validated by markmcclain, using the python-neutronclient does not seem a good option at this point
18:30:52 <s3wong> SumitNaiksatam: so we are going with direct calls (as in PoC)?
18:30:52 <LouisF> SumitNaiksatam: what are the alternatives here?
18:31:01 <rkukura> So do we all agree our current plan is to stick with the direct plugin calls, with code to invoke notifiers, etc., until the WSGI front end refactoring provides a better solution?
18:31:28 <SumitNaiksatam> s3wong: as is in the current patch: https://review.openstack.org/#/c/105272
18:31:35 <mandeep__> s3wong: As in the latest patch ... that is an update from the implementation in the PoC
18:32:17 <mandeep__> LouisF: Direct calls to Controller Object vs. using pyhton-neutronclient API
18:32:21 <SumitNaiksatam> LouisF: we have only two alternatives, make direct calls (since we are in the same process space), or use the python-neutronclient library (though we are in the same process space)
18:32:44 <SumitNaiksatam> LouisF: but rkukura determined that the later is not feasible for more than one reason
18:33:33 <rkukura> we also discussed using the Controller instances, but there is no way to do that currently, and markmcclain doesn’t want to enable this because code depending on this would have to change as the front end is refactored
18:33:35 <SumitNaiksatam> LouisF: eventually, there is a plan to refactor the current WSGI framework, such that it will be easier to route these calls, and GP will make use of that
18:33:50 <SumitNaiksatam> rkukura: okay
18:33:52 <rkukura> markmcclain: Please let me know if I’m misrepresenting any of what you said
18:34:04 <LouisF> SumitNaiksatam: ok
18:34:36 <markmcclain> rkukura: you've accurately recreated the convo :)
18:34:38 <rkukura> The initial front end refactoring will not break the way we are currently doing the direct plugin calls
18:34:57 <regXboi> so... if we aren't using neutronclient, what about horizon or HEAR?
18:34:59 <regXboi> er HEAT?
18:35:07 <SumitNaiksatam> rkukura markmcclain: nice!
18:35:14 <rkukura> regXboi: They should continue to use neutronclient
18:35:31 <SumitNaiksatam> regXboi: as rkukura said they will
18:35:31 <rkukura> They are separate processes, with seperate test environments
18:35:45 <SumitNaiksatam> regXboi: what we are discussing here are the internal calls
18:36:22 <mandeep__> regXboi: The issues was in calling python-neutronclient from a driver
18:36:26 <SumitNaiksatam> regXboi: the calls which the group policy mapping driver makes to the neutron core plugin to create the “traditional” neutron resources, once the mapping from the group policy resource to the neutron resource is established
18:36:35 <regXboi> got it
18:36:43 <regXboi> I was reading it the other way round
18:36:47 <SumitNaiksatam> regXboi: you would be excused for wondering why one would the python-neutronclient for this :-)
18:37:14 <regXboi> well that was going to be my next question, yes :)
18:37:17 <SumitNaiksatam> regXboi: the CLI and client the GP resources is as planned
18:37:42 <SumitNaiksatam> *for the GP resources
18:37:44 <regXboi> SumitNaiksatam: thx ...
18:37:55 <SumitNaiksatam> ok anything else for rkukura?
18:38:10 <rkukura> Anyway, given the above, I’m hopefully we can get the gp-api-1 -> gpm-rmd-1 stream of patches merging next week
18:38:17 <regXboi> this may not fit here
18:38:22 <SumitNaiksatam> rkukura: amen!
18:38:28 <SumitNaiksatam> regXboi: go ahead
18:38:34 <rkukura> especially if we can get rudra to submit a functional test
18:38:39 <regXboi> but do we have patches for the CLI and client changes? ( I may have missed them)
18:38:55 <SumitNaiksatam> regXboi: yes we do, and we have a separate agenda item as well
18:39:04 <regXboi> ok, I'll be quiet then :)
18:39:06 <SumitNaiksatam> regXboi: all patches linked from: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches
18:39:16 <SumitNaiksatam> regXboi: see CLI and horizon at teh bottom of that page
18:39:23 <LouisF> SumitNaiksatam: also horizon work
18:39:25 <regXboi> yep... got it
18:39:29 <SumitNaiksatam> LouisF: yes
18:39:48 <SumitNaiksatam> LouisF: WIP patch was posted, and we do have a separate agenda item
18:40:00 <SumitNaiksatam> rkukura: thanks for the update, any blockers for you?
18:40:17 <rkukura> nothing other than needing to do a lot of spec review before the deadline for those
18:40:24 <SumitNaiksatam> rkukura: :-)
18:40:36 <SumitNaiksatam> #topic Security Groups mapping update
18:40:41 <SumitNaiksatam> s3wong: hi
18:40:44 <s3wong> hello
18:41:07 <s3wong> So I have updated the google doc to reflect on preliminary idea on how to map to SG
18:41:17 <s3wong> #link https://docs.google.com/document/d/134P7TJdiIfjPWbmstSTY4vp9E6oRYTFs64ON3thFxhI/edit#
18:41:46 <s3wong> please comment (mostly the last section: "Contract Rendering Workflow")
18:42:18 <rkukura> s3wong: I’ll read/comment the doc, but is the current plan to use one SG per EPG?
18:42:38 <s3wong> rkukura: one SG per contract providing EPG
18:42:42 <SumitNaiksatam> rkukura: i was thinking more on this
18:42:58 <SumitNaiksatam> rkukura s3wong: i think we probably need on SG per EPG for the default rules
18:43:07 <s3wong> rkukura: SG created when both consuming and providing EPGs are known
18:43:09 <SumitNaiksatam> and then one SG per Contract
18:43:35 <SumitNaiksatam> i had not realized earlier that you can associate multiple SGs with a neutron port, but you can
18:43:49 <rkukura> I think we should create the SG at the same time we create the EPG, and set that SG on all EPs within that EPG
18:43:51 <s3wong> SumitNaiksatam: yes, I found out about that recently as well
18:43:59 <SumitNaiksatam> with that, i believe the above mapping would wor
18:44:01 <SumitNaiksatam> *wrok
18:44:05 <regXboi> SumitNaiksatam: +1
18:44:17 <rkukura> Then just add/modifiy/delete rules within it as contracts/policies/rules change
18:44:23 <SumitNaiksatam> but i am not what is the order in that case
18:45:09 <rkukura> Oh, I misssed the multiple SGs thing
18:45:19 <SumitNaiksatam> i mean to say i dont what how the SGs are ordered when more than one SG is associated with a neutron port
18:45:37 <SumitNaiksatam> fyi - #link http://docs.openstack.org/admin-guide-cloud/content/securitygroup_workflow.html
18:45:39 <rkukura> So the API allows it, but are the semantics defined?
18:45:49 <SumitNaiksatam> rkukura: not sure
18:45:53 <SumitNaiksatam> rkukura: need to check the code
18:46:03 <SumitNaiksatam> s3wong: any chance you got to explore that?
18:46:30 <s3wong> SumitNaiksatam: I saw that the API allows multiple SGs to be associated per port
18:46:46 <SumitNaiksatam> s3wong: yeah, i guess we need to try this out
18:46:58 <s3wong> SumitNaiksatam: agreed
18:47:32 * regXboi suspects that the implementation doesn't care about priority
18:47:32 <s3wong> SumitNaiksatam: rkukura: but in any case, the CIDR field would allow us to ensure applying appropriate rules to traffic flow, right?
18:47:55 <rkukura> If multiple SGs/port helps, great. But is there any reason we can’t make it work with one SG (per EPG) if needed?
18:47:58 <SumitNaiksatam> regXboi: yeah, probably, so its messy
18:48:24 <SumitNaiksatam> rkukura: we can make it work with one SG per EPG as well
18:48:35 <SumitNaiksatam> rkukura: but then we have to preserve more mapping
18:48:37 <regXboi> SumitNaiksatam: unless you want to know which SG is matched, then I don't think it is
18:48:39 <mandeep__> rkukura: It would make thde code (and it's updates) much cleaner with one SG per contract (and multiple per port)
18:48:43 <rkukura> I guess if the default rule is deny, and any SG on the port can allow, we might be able to use this
18:48:51 <regXboi> but of course, we would like to know which SG is matched :)
18:49:50 <mandeep__> rkukura: You have a point ... the white-list approach handles the ordering issues
18:50:02 <SumitNaiksatam> s3wong: i did not quite understand your question, i am still processing :-(
18:50:07 <regXboi> um...
18:50:21 <regXboi> Aren't neutron SGs whitelists by definition?
18:50:29 <SumitNaiksatam> regXboi: yes
18:50:30 <s3wong> regXboi: yes they are
18:50:46 <mandeep__> regXboi: As are GBP rules
18:50:55 <regXboi> ok - rkukura confused me for a second
18:51:11 <SumitNaiksatam> oh shoot, we have only 10 mins left in the meeting!
18:51:29 <SumitNaiksatam> s3wong: thanks for spending time and leading this
18:51:36 <s3wong> SumitNaiksatam: port w/ SG with rules XYZ && CIDR 10.0.1.0/24 and rules ABC && CIDR 10.0.2.0/24
18:51:41 <SumitNaiksatam> s3wong: i believe we need some more offline discussions on this
18:51:56 <SumitNaiksatam> s3wong: ok i will respond to your email thread, thanks!
18:52:01 <s3wong> SumitNaiksatam: cool
18:52:04 <SumitNaiksatam> s3wong: thanks for the update
18:52:25 <SumitNaiksatam> #topic API Intercept
18:52:48 <SumitNaiksatam> kevinbenton: posted a spec for this: https://review.openstack.org/#/c/105695/
18:52:55 <SumitNaiksatam> kevinbenton: thanks much for the quick turnaround
18:53:09 <SumitNaiksatam> banix is also working on this
18:53:38 <SumitNaiksatam> this will allow us to get over the current limitation of not being able to support GP API and traditional Neutron API simultaneously
18:53:45 <rkukura> I suggest talking with markmcclain about how the refactored front end will support this
18:54:09 <kevinbenton> rkukura: what do you mean by the front-end in this case?
18:54:13 <SumitNaiksatam> rkukura: i am sure the new refactoring will have a way to do this
18:54:17 <rkukura> even if we need an interim solution
18:54:32 <SumitNaiksatam> rkukura: we are trying to work through an intermediate approach
18:54:53 <rkukura> markmcclain and I touched on this in our conversation, and it sounds like he has a specific solution in mind
18:55:42 <mandeep__> rkukura: I believe that kevinbenton and banix are at the mid-session summit with markmcclain
18:55:48 <SumitNaiksatam> rkukura markmcclain:  is there a spec/document that kevinbenton can look at?
18:55:56 <regXboi> mandeep__: yes on banix
18:56:07 <rkukura> banix is here, but not kevinbenton
18:56:08 * regXboi was supposed to be there but had to cancel :(
18:56:09 <SumitNaiksatam> kevinbenton could not make it
18:56:21 <kevinbenton> SumitNaiksatam: i am :-)
18:56:28 * mandeep__ Ooops
18:56:34 <SumitNaiksatam> kevinbenton: oh you made it? :-)
18:56:40 <kevinbenton> SumitNaiksatam: whoops. i am in this meeting
18:56:42 <rkukura> markmcclain will be submiting a spec today, but it will be mostly placeholder
18:56:43 <kevinbenton> not in MN
18:56:45 <SumitNaiksatam> kevinbenton: yeah :-)
18:57:40 <SumitNaiksatam> rkukura markmcclain kevinbenton: hopefully we will have a path forward on this, whichever is the most feasible (short and long term)
18:57:55 <SumitNaiksatam> kevinbenton: thanks much!
18:57:59 <rkukura> SumitNaiksatam: +1
18:58:03 <SumitNaiksatam> #topic Vendor drivers
18:58:18 <SumitNaiksatam> its great to see that a bunch of vendor drivers specs have been submitted
18:58:36 <SumitNaiksatam> we actually 5 GP driver submissions including ODL!
18:58:42 <mandeep__> SumitNaiksatam: +1
18:59:14 <SumitNaiksatam> thanks all, and the dependency is really on the base model patches to merge
18:59:17 <LouisF> SumitNaiksatam: links to these?
18:59:20 <SumitNaiksatam> #topic Open Discussion
18:59:25 <SumitNaiksatam> LouisF: they are in the agenda
18:59:29 <SumitNaiksatam> regXboi: go for it
18:59:39 <regXboi> so... revenge of multicast classifier
18:59:47 <SumitNaiksatam> regXboi: :-)
19:00:03 <regXboi> we really need a multicast policy classifier
19:00:14 <regXboi> the SDN-VE driver is going to use it
19:00:27 * SumitNaiksatam thinks we can stay in this meeting until we are kicked out (being optimistic that we are not)
19:00:36 <regXboi> because we have use cases around giving different policy to multicast traffic
19:00:53 <SumitNaiksatam> regXboi: okay
19:00:54 <mandeep__> LouisF: Look under "Vendor/Open Source Controller Drivers". There are 5 backends proposed - ODL, Cisco, One Convergence, Nuage, and IBM
19:01:05 <regXboi> I'd like something very simple in the policyclassifier
19:01:13 <regXboi> and leave it to the drivers to do the necessary low level magic
19:01:21 <regXboi> is that possible?
19:01:21 <mandeep__> regXboi: Did you want to write that up a BP?
19:01:28 <regXboi> today?
19:01:33 * regXboi goes ouch
19:01:40 <SumitNaiksatam> regXboi: one of the approaches could be to use resource extension
19:01:49 <mandeep__> That way, it's implementation in the reference implementation does not become an issue
19:01:54 <SumitNaiksatam> regXboi: it could be made part of the IBM SDN-VE bp spec
19:02:13 <regXboi> SumitNaiksatam: I'll get with banix on that approach
19:02:20 <mandeep__> SumitNaiksatam: Yes, that can done as a resource extension. Good point
19:02:22 <regXboi> because that looks to be the best way forward
19:02:29 <SumitNaiksatam> regXboi: so we would be creating a new extended policy classifier resource which adds the multicast field
19:02:43 <regXboi> SumitNaiksatam: something like that, yes
19:02:57 <SumitNaiksatam> regXboi: once we have enough consensus, we can promote that attribute to the policy classifier itself
19:03:22 <regXboi> I think that will work for me
19:03:25 <SumitNaiksatam> regXboi: but at least for the time being it will unblock the IBM driver, and will provide it with a way to use it
19:03:25 <mandeep__> regXboi: (Sorry, I know that the BP deadline being today)
19:03:51 <regXboi> since the SDN-VE bp spec is already there, we can piggyback
19:04:00 <regXboi> so I don't need to write a *new* bp
19:04:02 <SumitNaiksatam> regXboi: exactly
19:04:08 <mandeep__> regXboi: ;-)
19:04:10 <SumitNaiksatam> regXboi: thats my thinking
19:04:13 <regXboi> and that was my concern, given folks are in MN
19:04:24 * regXboi notes "great minds...."
19:04:28 <SumitNaiksatam> regXboi: understand
19:04:36 <SumitNaiksatam> any other questions/thoughts/comments?
19:04:42 <regXboi> ok, that works for me - thanks!
19:04:45 <regXboi> and I'm good :)
19:04:51 <rkukura> +1
19:04:54 <SumitNaiksatam> regarding CLI/client
19:04:58 <SumitNaiksatam> songole: there?
19:05:07 <SumitNaiksatam> anything blocked at your end?
19:05:17 <songole> SumitNaiksatam: No.
19:05:26 <songole> I am starting on the 2nd patch set
19:05:29 * regXboi pads away to discuss "cow" things
19:05:33 <SumitNaiksatam> ah, just typing that :-)
19:05:52 <SumitNaiksatam> you can start with the other resources as well (easy for me to say :-P)
19:05:59 <SumitNaiksatam> is ronak here?
19:06:15 <SumitNaiksatam> i was hoping to get a Horizon update
19:06:47 <SumitNaiksatam> #action SumitNaiksatam to ping Ronak on the state of Horixon
19:06:57 <songole> I meant 2nd API set for other resources..
19:07:08 <SumitNaiksatam> songole: yes, thats what i meant
19:07:32 <songole> ok
19:07:32 <SumitNaiksatam> anything else that we need to discuss since we have not yet been kicked out?
19:08:04 <SumitNaiksatam> alrighty, thanks everyone!
19:08:08 <s3wong> thanks
19:08:10 <SumitNaiksatam> #endmeeting