18:00:53 <SumitNaiksatam> #startmeeting networking_policy
18:00:54 <openstack> Meeting started Thu Jul  3 18:00:53 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:57 <openstack> The meeting name has been set to 'networking_policy'
18:01:05 <SumitNaiksatam> #info agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
18:01:18 <SumitNaiksatam> #info Juno specification submission deadline: July 10th, specification approval deadline: july 17th
18:01:57 <banix> SumitNaiksatam: hi
18:02:04 <SumitNaiksatam> we need to revisit and check if we need to submit any more blueprints for the stuff we haven’t addressed yet (outside of what is in the group policy umbrella blueprint)
18:02:12 <s3wong> hello
18:02:13 <SumitNaiksatam> banix: hi again :-)
18:02:29 <s3wong> Seems like meeting has started...
18:02:45 <SumitNaiksatam> s3wong: yeah welcome, just started, you were called out earlier :-P
18:02:52 <SumitNaiksatam> s3wong: AIs assigned!
18:03:14 <SumitNaiksatam> #topic Resource Model/API/DB/Plugin Update
18:03:42 <SumitNaiksatam> So all patches have been posted now (later patches need a rebase)
18:04:19 <SumitNaiksatam> and have been using a patch name convention: GP-API/DB/PLG/1/2/3
18:04:24 <rkukura> SumitNaiksatam: Is any update expected to these at this point?
18:04:35 <SumitNaiksatam> * GP-API/DB/PLG-1/2/3
18:05:05 <SumitNaiksatam> rkukura: i dont think there are any outstanding comments for GP-API/DB/PLG-1
18:05:27 <SumitNaiksatam> rkukura: well apart from the one you had for driver UTs,
18:05:40 <SumitNaiksatam> and i have not put the DB migration script yet
18:05:56 <SumitNaiksatam> but i dont think i will be doing these today
18:06:11 <rkukura> SumitNaiksatam: I think Paul Michali put a -1 on the latest gp-api-1 regarding copy.copy()
18:06:21 <SumitNaiksatam> rkukura: ah i didnt see that
18:06:45 <SumitNaiksatam> copy.copy() was used per markmcclain’s comments
18:06:55 <rkukura> SumitNaiksatam: It would be good to know if this will force a quick update, or is not really an issue
18:06:58 <SumitNaiksatam> i will take a look as to what pcm’s comment is
18:07:11 <rkukura> SumitNaiksatam: Thanks
18:07:54 <SumitNaiksatam> rkukura: i dont understand the comment as much
18:08:09 <SumitNaiksatam> rkukura: using copy() versus copy.copy() or copy.deepcopy()
18:08:34 <SumitNaiksatam> deepcopy() is required wherever there are nested args, so i am not sure why a shallow copy would be used there
18:08:45 <rkukura> I think he is concerned that copy.copy() copies the dictionary, but does not copy the items in it
18:08:56 <SumitNaiksatam> i dont know the difference between copy() versus copy.copy()
18:09:17 <rkukura> I think copy.copy() is fine if its a dict of string->string mappings
18:09:25 <SumitNaiksatam> rkukura: copy.copy() does a shallow copy, right?
18:09:28 <SumitNaiksatam> rkukura: yeah
18:09:47 <rkukura> But if its a dict of dicts, then copy.deepcopy() may be needed if the nested dicts should be copied.
18:09:51 <SumitNaiksatam> rkukura: so currently copy.copy() and copy.deepcopy() is used selectively whereever appropriate
18:10:09 <SumitNaiksatam> at least that was the intention
18:10:49 <SumitNaiksatam> ok i will go back and check
18:10:52 <rkukura> His comment is about a dict of dicts
18:11:07 <SumitNaiksatam> rkukura: so that needs a deepcopy(), and i believe thats what i have
18:11:24 <rkukura> line 79 is a copy.copy()
18:11:38 <rkukura> I’m not sure its really a problem.
18:11:50 <SumitNaiksatam> rkukura: okay i will check after the meeting
18:11:57 <rkukura> Thanks
18:12:01 <SumitNaiksatam> rkukura: expect another rev in that case
18:12:30 <SumitNaiksatam> per reviewer’s comment there is a change in base URI: /gp --> /grouppolicy
18:12:37 <SumitNaiksatam> any objections?
18:12:45 <SumitNaiksatam> its more typing if you are doing this manually
18:13:05 <SumitNaiksatam> and the convention in neutron earlier was to use acronyms like lbaas, fwaas, etc
18:13:20 <SumitNaiksatam> but i went with the suggestion to spell it ouy
18:13:23 <SumitNaiksatam> *out
18:13:36 <SumitNaiksatam> attribute name change: default_subnet_prefix_length --> subnet_prefix_length
18:13:50 <rkukura> SumitNaiksatam: Thanks!
18:14:00 <SumitNaiksatam> hopefully there are not more name changes
18:14:17 <SumitNaiksatam> so we did a quick rev on the group policy spec to reflect all the name changes
18:14:24 <SumitNaiksatam> actually mestery did that (thanks!)
18:14:26 <banix> SumitNaiksatam: grouppolicy is good
18:14:28 <rkukura> I really did not want a config variable in the implicit_policy driver called default_default_subnet_prefix_length!
18:14:45 <SumitNaiksatam> however the above attribute name change is not reflected in that
18:14:48 <SumitNaiksatam> rkukura: ok
18:14:51 <SumitNaiksatam> banix: ok
18:15:14 <songole> SumitNaiksatam: how about CLI commands? Use gp_ or grouppolicy_ ?
18:15:16 <SumitNaiksatam> so in general (off-topic), has anyone pulled the neutron-spec repo recently?
18:15:32 <SumitNaiksatam> songole: thanks for bringing that up, lets take that up in CLI update
18:15:39 <rkukura> I don’t care about gp_ vs. grouppolicy_, but we need to nail it down ASAP
18:15:52 <songole> SumitNaiksatam: ok
18:16:05 <s3wong> SumitNaiksatam: I have - anything wrong?
18:16:13 <rkukura> I meant in the URIs
18:16:19 <SumitNaiksatam> s3wong:  i dont seee the latest merges
18:16:27 <SumitNaiksatam> rkukura: songole’s question was not on the URI
18:16:45 <SumitNaiksatam> s3wong: the latest commit i saw in that repo was june 25th
18:16:46 <rkukura> realized that
18:17:02 <SumitNaiksatam> #link https://github.com/openstack/neutron-specs
18:17:19 <SumitNaiksatam> but a bunch of patches have been “merged” since
18:17:37 <SumitNaiksatam> so i wanted to put one more rev for the GP-spec, but i couldnt make progree
18:17:41 <s3wong> SumitNaiksatam: hmm... OK, I saw the files, didn't check the date
18:17:49 <SumitNaiksatam> anyone have any idea?
18:17:54 <SumitNaiksatam> s3wong: see the latest commit
18:18:32 <s3wong> SumitNaiksatam: 8 days ago...
18:18:36 <SumitNaiksatam> s3wong: yeah
18:18:39 <SumitNaiksatam> and thats not right
18:19:04 <SumitNaiksatam> so i dont know, perhaps a question for the infra team, i did not get a chance to follow up
18:19:29 <SumitNaiksatam> anyone, whenever this gets sorted please expect another minor rev, with the attribute name change
18:20:13 <SumitNaiksatam> anything anyone else wanted to edit in the spec (any inconsistency?) please let me know, or if you want to post the update please go ahead, and include the update to the subnet_prefix_length attribute (coordinate with me)
18:20:34 <SumitNaiksatam> rkukura had comments on adding explicit UT on the plugin patch
18:20:50 <SumitNaiksatam> the code path for the dummy driver currently gets exercised
18:20:59 <SumitNaiksatam> with the existing UTs
18:21:13 <SumitNaiksatam> but it will be good to have specific UTs and will help with the downstream patches
18:21:18 <rkukura> yes, that patch didn’t verify that the right driver methods get called with context objects containing the right data
18:21:20 <SumitNaiksatam> So banix is working on adding driver-specific UTs to GPM-PLG-1
18:21:39 <rkukura> SumitNaiksatam, banix: great!
18:21:46 * banix wakes up
18:21:53 <SumitNaiksatam> banix: :D
18:22:14 <banix> sorry guys :) just kidding. I have been following
18:22:30 <SumitNaiksatam> i have also not put the DB migration script in GP-DB-1
18:22:58 <SumitNaiksatam> whats the thinking, should we add it upfront, or should we add one script at the end of the series?
18:24:04 <SumitNaiksatam> ok, let me know if you have thoughts
18:24:15 <SumitNaiksatam> #topic Mapping Model/Driver Update
18:24:18 <SumitNaiksatam> rkukura: over to you
18:24:18 <rkukura> Does not having the migration actually prevent deploying neutron-server with the plugin?
18:24:37 <SumitNaiksatam> rkukura: perhaps, so its required upfront
18:24:43 <SumitNaiksatam> will add it
18:25:11 <SumitNaiksatam> and we can modify the same script in the subsequent patches
18:25:12 <rkukura> I was on PTO most of the past week, but managed to make some progress, especially while stuck at JFK most of yesterday
18:25:39 * SumitNaiksatam notes that JFK is productive office location
18:25:41 <rkukura> The implicit_driver patch is done, but it and the other gpm-* patches need to be rebased
18:25:56 <rkukura> Free wi-fi in the wine bar next to our gate helped
18:26:33 * SumitNaiksatam notes that wine bar is an important detail
18:26:53 <rkukura> kept my wife from being too annoyed that I was working
18:26:54 <SumitNaiksatam> rkukura: great, good to hear about the implicit-driver
18:27:04 <banix> big storm came through the city
18:27:07 <banix> yesterday
18:27:20 <rkukura> So I will rebase gpm-ipd and the other gpm-* patches and post today
18:27:27 <SumitNaiksatam> rkukura: ok great
18:27:43 <SumitNaiksatam> rkukura: the mapping dirver, how is that coming along?
18:27:46 <rkukura> I’m now going to get the gpm-rmd (resource_mapping driver) into a functional state and post ASAP
18:28:24 <SumitNaiksatam> rkukura: great, i guess we need that in ASAP to get past the current -2 on the first patch
18:28:24 <s3wong> rkukura: which repo has you been working off of? I couldn't find it on noironetworks/neutron-group-policy
18:28:24 <rkukura> Hopefully this will all some if the Sumit’s initial patches to start merging, even if this one is still WIP
18:28:46 <SumitNaiksatam> rkukura: yes, i agree, i think its a reasonable expectation
18:28:47 <rkukura> s3wong: I’m working off gerrit
18:28:59 <banix> hi
18:29:05 <s3wong> rkukura: I see
18:29:09 <banix> sorry oops wrong window
18:29:39 <SumitNaiksatam> rkukura: any blockers, or anything you wanted to bring up for discussion?
18:29:52 <rkukura> I should be able to make some progress on gpm-rmd over the long weekend (since I’ve just had a nice vacation) and hopefully have it pretty much complete by Monday.
18:30:03 <SumitNaiksatam> rkukura: ok
18:30:04 <s3wong> rkukura: OK - I will need to look at your mapping driver part to think about the contract rendering part
18:30:19 <rkukura> No blockers right now, just need to know whether to rebase on the current gp-* patches or wait for updates
18:30:55 <SumitNaiksatam> rkukura: ok, i have to run to another meeting immediately after this, but will get to it later in the day after that
18:30:59 <s3wong> rkukura: SumitNaiksatam: in the mean time, I will look at SumitNaiksatam 's latest contract API/DB patches to see which fields need to get into mapping DB
18:31:01 <rkukura> s3wong: Hopefully a WIP patch, probably missing UTs, will help with that
18:31:02 <SumitNaiksatam> rkukura: i will update once i am done
18:31:13 <s3wong> rkukura: I am sure it will :-)
18:31:23 <SumitNaiksatam> s3wong: thanks, we have a separate agenda item for you :-)
18:31:33 <SumitNaiksatam> rkukura: thanks for the update
18:31:47 <SumitNaiksatam> #topic CLI/Client update
18:31:55 <SumitNaiksatam> songole: over to you
18:32:05 <songole> API-1 patch is posted
18:32:16 <songole> https://review.openstack.org/#/c/104013/
18:32:33 <SumitNaiksatam> songole: sweet, thanks so much for jumping on it in hemanth’s absence and getting it ready in quick time
18:32:34 <songole> I will update the name changes
18:32:40 <SumitNaiksatam> songole: thanks
18:32:56 <songole> So, should it be gp_ or grouppolicy_?
18:33:01 <SumitNaiksatam> songole: so you had a question on whether CLI should start with gp- or grouppolicy-
18:33:06 <SumitNaiksatam> songole: yeah
18:33:23 <SumitNaiksatam> i think the current practice in neutron is to spell it out?
18:33:29 <banix> i think grouppolicy_ would be better at the end of the day with auto completion etc
18:33:50 <rkukura> Are acronyms used for the other services?
18:34:01 <SumitNaiksatam> i dont have a devstack ready here to check quickly
18:34:15 <SumitNaiksatam> rkukura: i think we are probably using a mixed approach
18:34:30 <SumitNaiksatam> s3wong: do we go loadbalancer- or lb- in the lbaas CLI?
18:34:36 <rkukura> I like acronyms ;)
18:34:44 <SumitNaiksatam> i know for fwaas we have “fw-“
18:34:48 <songole> vpn, lb
18:34:53 <SumitNaiksatam> rkukura: yes, we all kknow that :-)
18:34:55 <banix> neutron router-interface-add ….
18:35:08 <s3wong> SumitNaiksatam: I think it is 'loadbalancer'
18:35:15 <SumitNaiksatam> yeah, i think we have been using a mixed approach
18:35:17 <songole> SumitNaiksatam: it is lb_
18:35:32 <s3wong> songole: seems like I got it wrong :-)
18:35:33 <songole> floatingip is expanded
18:35:33 <rkukura> I like acronyms, but I don’t like “shortenned” words
18:35:43 <SumitNaiksatam> there is probably a character threshold beyond which we resort to acronyms
18:36:12 <SumitNaiksatam> to banix’s earlier point, CLI is auto completed
18:36:28 <SumitNaiksatam> so we really dont need to type even if we have the long form
18:36:48 <SumitNaiksatam> (my personal perference is also with the acronym)
18:37:00 <SumitNaiksatam> but perhaps we can roll with “grouppolicy_”?
18:37:23 <SumitNaiksatam> the two ‘p’s in between make it tricky if you chose not to autocomplete
18:37:58 <songole> SumitNaiksatam: agree
18:38:15 <s3wong> SumitNaiksatam: so what was the reviewer's reason to move from 'gp' to 'grouppolicy'?
18:38:23 <s3wong> that 'gp' can mean something else?
18:38:48 <SumitNaiksatam> s3wong: i dont know
18:38:53 * regXboi wanders in late with a classifier question for the open discussion
18:39:04 <SumitNaiksatam> regXboi: sure we will have time for that
18:39:13 <regXboi> SumitNaiksatam: thx
18:39:24 <SumitNaiksatam> s3wong: i chose not to deliberate too much on subjective issues
18:39:38 <s3wong> SumitNaiksatam: fair enough :-)
18:39:46 <songole> SumitNaiksatam: so, the consensus is grouppolicy_?
18:40:13 <SumitNaiksatam> any objections?
18:40:18 <rkukura> My vote would be gp_, but won’t object
18:40:25 <banix> no objections
18:40:38 <SumitNaiksatam> i will take that as a no objection from rkukura
18:40:41 <s3wong> doesn't matter, really :-) do have to settle on one
18:40:46 <regXboi> I'd agree with rkukura, as it is shorter to type, but I won't object either
18:40:55 <SumitNaiksatam> regXboi: you dont need to type
18:41:00 <SumitNaiksatam> regXboi: its auto completed
18:41:30 <SumitNaiksatam> regXboi: however we the base URI is /grouppolicy, in case if some level of consistency needs to exist between them
18:41:45 <SumitNaiksatam> dont hear any objections yet
18:41:47 <regXboi> consistency is always good
18:41:55 <SumitNaiksatam> ok, done then!
18:42:21 <SumitNaiksatam> #agreed CLI prefix is grouppolicy_ (not gp_)
18:42:28 <songole> ok
18:42:35 <SumitNaiksatam> songole: any other blockers for you?
18:42:50 <songole> no. I am unblocked!
18:43:14 <SumitNaiksatam> songole: nice, and thanks again for stepping up on this!
18:43:31 <SumitNaiksatam> we are running a bit slow today
18:43:42 <SumitNaiksatam> #topic Security Group mapping update
18:43:47 <SumitNaiksatam> s3wong: over to you
18:43:55 <SumitNaiksatam> progress?
18:44:03 <SumitNaiksatam> i know you ahve dependency
18:44:13 <SumitNaiksatam> but still… ;-P
18:44:14 <s3wong> So as we talked about last week, it seems like the only item that needs to be added to mapping DB would be the security group ID
18:44:42 <SumitNaiksatam> s3wong: do we have a document? or perhaps edit to the existing mapping google doc, to capture your thoughts?
18:45:17 <s3wong> SumitNaiksatam: yes, documentation is the first step - where is the existing mapping doc?
18:45:37 <rkukura> s3wong: Any thoughts on whether to incrementally modify the SGs as various policies change, or just trigger regenerating them?
18:45:47 <SumitNaiksatam> s3wong: its linked somewhere from the wiki :-P
18:45:53 <s3wong> SumitNaiksatam: OK
18:46:14 <SumitNaiksatam> #link https://docs.google.com/a/noironetworks.com/document/d/134P7TJdiIfjPWbmstSTY4vp9E6oRYTFs64ON3thFxhI/edit?usp=sharing
18:46:21 <SumitNaiksatam> s3wong: ^^^
18:46:44 <SumitNaiksatam> s3wong: sorry for being pushy, but when can we expect an update?
18:46:47 <s3wong> rkukura: I am thinking at this point we have one security group for the whole contract, and have each policy-rule be added as incremental update
18:47:05 <s3wong> rkukura: do you see any potential problem?
18:47:05 <SumitNaiksatam> s3wong: ok
18:47:30 <s3wong> SumitNaiksatam: yes, after the Service Insertion spec update, I will update the doc to reflect on my thoughts
18:47:33 <mandeep> s3wong: ok
18:47:35 <rkukura> s3wong: I was thinking we’d need a SG per EPG or something like that
18:48:21 <s3wong> rkukura: OK - but if an EPG consumes or provides more than one contracts, do we simply consolidate?
18:48:32 <SumitNaiksatam> s3wong: thanks!
18:48:49 <s3wong> rkukura: (and this also makes future expansion on stuff like label difficult to manage, right?)
18:49:01 <rkukura> s3wong: I was thinking that we’d need to merge the rules from all contacts into one SG. I don’t think a port can use more than one SG.
18:49:13 <rkukura> s/contacts/contracts/
18:49:25 <SumitNaiksatam> rkukura: i dont think so either
18:49:30 <s3wong> rkukura: Oh, OK. That makes sense - have to work with limitation on SG
18:49:53 <banix> yup one sg
18:49:55 <rkukura> If an EPG has multiple subnets, I think they could all use the same SG, but I’m not sure
18:50:13 <SumitNaiksatam> #action sync up between s3wong rkukura mandeep SumitNaiksatam on SG mapping, s3wong to put some initial thoughts in https://docs.google.com/a/noironetworks.com/document/d/134P7TJdiIfjPWbmstSTY4vp9E6oRYTFs64ON3thFxhI/edit?usp=sharing
18:50:31 <s3wong> SumitNaiksatam: will update the doc over the Indpendence Day weekend
18:50:44 <SumitNaiksatam> s3wong: thanks!
18:50:55 * SumitNaiksatam realizes he is not making too many friends here!
18:51:23 <SumitNaiksatam> s3wong: so on the code front you have a dependency, and are blocked
18:51:24 <s3wong> SumitNaiksatam: well, if rkukura works during his PTO, it is only appropriate that I also work during ID4 :-)
18:51:54 <s3wong> SumitNaiksatam: yes, for one, action isn't defined yet from your contract patch
18:52:24 <rkukura> s3wong: I intended to get a lot more work done than I actually did, so please don’t feel any obligation
18:52:30 <s3wong> SumitNaiksatam: and (2) I would like to see rkukura 's mapping driver patch once it is available
18:52:46 <SumitNaiksatam> s3wong: ok, makes sense
18:53:06 <SumitNaiksatam> s3wong: i think as long as we have a plan in place, please shout out to us if you are blocked
18:53:15 <s3wong> rkukura: cool :-)
18:53:22 <s3wong> SumitNaiksatam: certainly
18:53:37 <SumitNaiksatam> we have our backs to the wall in terms of J2 deadline
18:53:44 <s3wong> SumitNaiksatam: I was stuck in an event over the last two days, so progress has been slow... sorry about that
18:53:57 <regXboi> um... quick acro expansion: SG = ??
18:54:00 <SumitNaiksatam> s3wong: np at all
18:54:07 <SumitNaiksatam> regXboi: security group
18:54:09 <s3wong> regXboi: security group
18:54:10 <mandeep> regXboi: Security Group
18:54:11 <regXboi> ah thanks
18:54:19 <SumitNaiksatam> s3wong: thanks much for the update
18:54:28 <regXboi> I was suddenly thinking service g.... and getting confused :)
18:54:53 <SumitNaiksatam> #topic services’s integration
18:54:58 <SumitNaiksatam> banix: any thoughts?
18:55:01 <SumitNaiksatam> or update
18:55:05 <s3wong> damn, me again :-) ?
18:55:12 <banix> to s3wong
18:55:16 <SumitNaiksatam> s3wong: i tried to be subtle
18:55:30 <SumitNaiksatam> s3wong: you can blame banix now! :-P
18:55:41 <s3wong> So last week I met with mandeep and SumitNaiksatam , and decided to not wait for ServiceBase for 'redirect'
18:56:20 <SumitNaiksatam> s3wong: ok good, i believe there is a bit of dependency there as well on the driver patches that are expected
18:56:26 <SumitNaiksatam> s3wong: thanks for that update
18:56:32 <SumitNaiksatam> #topic open discussion
18:56:38 <SumitNaiksatam> regXboi: go for it
18:56:38 <regXboi> may I?
18:56:49 <regXboi> so I was reviewing the GBP patch sets
18:56:56 <SumitNaiksatam> regXboi: yes thanks
18:57:03 <regXboi> and I'm missing a policy classifier that goes beyond the protocol
18:57:19 <regXboi> specifically I have a use case where I want to look at the first octet of the MAC
18:57:27 <regXboi> because of different policies for multicast traffic
18:57:59 <mandeep> regXboi: By design the classifiers are L4+ and the endpoints (L3 and below) are expected to be identified by group membership
18:58:08 <regXboi> doesn't matter
18:58:18 <mandeep> regXboi: We need to think of multicast specifically
18:58:38 <regXboi> I'm saying that an L4+ classifier appears to miss the boat
18:58:45 <SumitNaiksatam> regXboi: i believe our current classifier definition is extensible
18:59:02 <mandeep> regXboi: I get your point on multicast, and I agree that it is an problem
18:59:04 <regXboi> SumitNaiksatam: I hope so, because I'm going to put comments in looking to do that
18:59:18 <regXboi> so be prepared to see some comments on the classifiers for that
18:59:21 <SumitNaiksatam> regXboi: sure, and duly noted
18:59:28 <regXboi> otherwise the patch sets will be getting +1s from me down the line
18:59:43 <regXboi> (for what it is worth)
18:59:57 <regXboi> SumitNaiksatam: that was all I had
18:59:57 <SumitNaiksatam> regXboi: definitely helps a lot to get the +1
19:00:21 * regXboi stole the first X minutes of this meeting to actually *DO* the reading :)
19:00:26 <SumitNaiksatam> regXboi: as long as there is a path to evolve, i think we should keep rolling
19:00:46 <SumitNaiksatam> regXboi: otherwise we are not going to get this update off the ground
19:00:50 <mandeep> regXboi: I agree that the multicast use case needs to be resolved (as opposed to that we need to extend the classifier to L3 and below ;-)
19:01:01 <regXboi> SumitNaiksatam: I'm good with that - I'll probably leave the ones with comments at 0 for the nonce
19:01:06 <regXboi> so I'm not blocking
19:01:17 <SumitNaiksatam> regXboi: sure
19:01:24 <regXboi> mandeep: I'd prefer not to have different mechanisms
19:01:31 <s3wong> mandeep: yes, hopefully you don't go back to discussing adding IP addresses and what not in classifier
19:01:42 * regXboi cringes
19:01:46 <mandeep> s3wong: That was the point that I was making
19:01:51 <SumitNaiksatam> ok we are runnning a couple of mins over
19:02:06 <regXboi> who will be in MN next week?
19:02:13 <regXboi> we can talk about this then...
19:02:28 <SumitNaiksatam> i cant make it
19:02:36 <banix> i think apart from me and you rkukura
19:02:37 <regXboi> :(
19:02:39 <mandeep> I will not be there either
19:02:40 <s3wong> won't be there, unfortunately
19:02:47 <regXboi> ok... so we'll take this to email then
19:03:05 <regXboi> I'll put together some thoughts in comments and we can branch from that
19:03:15 <s3wong> regXboi: sounds good
19:03:27 <mandeep> regXboi: may be a quick call will converge faster
19:03:30 <SumitNaiksatam> regXboi: sounds good, will follow up specifically on this with you
19:03:37 <SumitNaiksatam> what mandeep said
19:03:40 <regXboi> mandeep: the trick is finding time :(
19:03:49 <SumitNaiksatam> ok i will wrap it here
19:03:56 <SumitNaiksatam> thanks all and happy 4th of July!
19:03:57 <regXboi> banix will tell you: I'm a really popular guy
19:04:00 <SumitNaiksatam> #endmeeting