Summary of IRC Meeting in #apachehelix at Wed Apr 30 17:20:51 2014: Attendees: kanakb, osgigeek, kishoreg-helix
- Preface - APIs IRC log follows: ## Preface ## [Wed Apr 30 17:21:05 2014] <kanakb>: since osgigeek is here, we can talk about APIs ## APIs ## [Wed Apr 30 17:21:16 2014] <kishoreg-helix>: ok [Wed Apr 30 17:22:23 2014] <osgigeek>: Summary so far: API commands are in place, need to be fleshed out. Builders exist for the primary model entities, SPI project created but needs fleshing out [Wed Apr 30 17:22:39 2014] <osgigeek>: Summary (cont'd): kanakb: feedback is incorporated [Wed Apr 30 17:22:53 2014] <osgigeek>: kishoreg-helix: had some today morning whcih I will start looking into [Wed Apr 30 17:23:10 2014] <osgigeek>: kishoreg-helix: to try and write a recipe and figure what is missing [Wed Apr 30 17:23:30 2014] <osgigeek>: Roughly the steps ahead seem as such [Wed Apr 30 17:23:33 2014] <kishoreg-helix>: yes, i will first try to convert quickstart [Wed Apr 30 17:23:49 2014] <osgigeek>: (1) Try to make sure all APIs are in place for models [Wed Apr 30 17:23:58 2014] <osgigeek>: (2) Figure Event and Message interfaces [Wed Apr 30 17:24:02 2014] <osgigeek>: (3) Figure Rebalancers [Wed Apr 30 17:24:14 2014] <kanakb>: and looking at the emails, i see the following: [Wed Apr 30 17:24:16 2014] <osgigeek>: (4) Figure SPI packages, classes and interfaces [Wed Apr 30 17:24:26 2014] <kanakb>: - comparison of usability vs HelixAdmin [Wed Apr 30 17:24:31 2014] <osgigeek>: yes [Wed Apr 30 17:24:34 2014] <kanakb>: - services [Wed Apr 30 17:24:46 2014] <osgigeek>: yes that is feedback today morning I will work on [Wed Apr 30 17:25:14 2014] <osgigeek>: (5) Separate out helix-zk [Wed Apr 30 17:25:20 2014] <osgigeek>: (6) Clean up core [Wed Apr 30 17:25:25 2014] <osgigeek>: (7) End to end testing [Wed Apr 30 17:25:30 2014] <kishoreg-helix>: i would leave out (5) for now, its taking on too much [Wed Apr 30 17:25:40 2014] <kanakb>: and a concern Kishore had that i share somewhat is explosion in number of classes [Wed Apr 30 17:26:03 2014] <kanakb>: but as long as it scales with number of models and not number of attributes on models, it might be ok [Wed Apr 30 17:26:12 2014] <kishoreg-helix>: explosion os classes is mainly in commands rt [Wed Apr 30 17:26:28 2014] <kanakb>: yeah [Wed Apr 30 17:26:29 2014] <kishoreg-helix>: do u have that concern else where? [Wed Apr 30 17:26:30 2014] <osgigeek>: I will keep an eye on that for sure, you guys can keep me honest. But I will lean towards clarity in API than reducing # of classes [Wed Apr 30 17:26:51 2014] <kanakb>: it's probably fine... once we have a quickstart we'll know for sure [Wed Apr 30 17:26:58 2014] <osgigeek>: but yes point taken and noted that I have a TODO on number of commands [Wed Apr 30 17:27:21 2014] <kishoreg-helix>: i think kanak does not mean reducing classes literally [Wed Apr 30 17:27:22 2014] <kanakb>: the big thing is that code size should be roughly same or lower for all major use cases [Wed Apr 30 17:27:48 2014] <kanakb>: right [Wed Apr 30 17:28:08 2014] <osgigeek>: when we say code size how are you measuring it? [Wed Apr 30 17:28:13 2014] <osgigeek>: so I know how to measure it [Wed Apr 30 17:28:33 2014] <kishoreg-helix>: here is a quick example i can give [Wed Apr 30 17:28:54 2014] <kishoreg-helix>: i dont think it has to do with new api's [Wed Apr 30 17:29:17 2014] <kishoreg-helix>: for example, i want to read a particular key in a config for each partition [Wed Apr 30 17:29:49 2014] <kishoreg-helix>: the simplest way would be [Wed Apr 30 17:30:22 2014] <kishoreg-helix>: admin.getPartitionConfig(keyName, partitionId) [Wed Apr 30 17:30:38 2014] <osgigeek>: So we are talking about a query API, I dont think we should have an API sitting on admin for each of those [Wed Apr 30 17:30:46 2014] <osgigeek>: I think we should consider a Query construct [Wed Apr 30 17:30:59 2014] <osgigeek>: That is a scalable model [Wed Apr 30 17:31:11 2014] <osgigeek>: rather than figure APIs for each attribute they will query [Wed Apr 30 17:31:13 2014] <kishoreg-helix>: yes, i think every one agrees with that [Wed Apr 30 17:31:30 2014] <kishoreg-helix>: current admin model is not scalable either [Wed Apr 30 17:31:38 2014] <kishoreg-helix>: so how do we go about it [Wed Apr 30 17:31:54 2014] <kishoreg-helix>: i think we basically need an ORM model [Wed Apr 30 17:32:27 2014] <kishoreg-helix>: part of me says its design can be independent of helix [Wed Apr 30 17:32:53 2014] <osgigeek>: I dont think its independent [Wed Apr 30 17:33:02 2014] <osgigeek>: The query is not a generic query language [Wed Apr 30 17:33:12 2014] <osgigeek>: we need it to have specific constructs of the domain model [Wed Apr 30 17:33:29 2014] <kishoreg-helix>: i meant the pattern [Wed Apr 30 17:33:49 2014] <kishoreg-helix>: we have some tables [Wed Apr 30 17:33:56 2014] <kishoreg-helix>: and some fields in table [Wed Apr 30 17:34:01 2014] <osgigeek>: yes pattern should be existing patterns, i.e. there are probably existing query dialects we can borrow design from [Wed Apr 30 17:34:33 2014] <kishoreg-helix>: i could not find them, [Wed Apr 30 17:34:48 2014] <osgigeek>: here is my suggestion lets not design that here, lets take that as a TODO with a couple of us coming up with strategies to solve that and maybe put together a short writeup [Wed Apr 30 17:35:05 2014] <osgigeek>: I will look for them [Wed Apr 30 17:35:11 2014] <osgigeek>: see if I can dig up something [Wed Apr 30 17:35:17 2014] <osgigeek>: and try and send out a proposal [Wed Apr 30 17:35:44 2014] <osgigeek>: sorry I probably am a bit slow, did not get to the realization of the need for a query language just until this conversation [Wed Apr 30 17:36:22 2014] <kishoreg-helix>: its not really a full fledge query layer [Wed Apr 30 17:36:45 2014] <kishoreg-helix>: i think before we dive into it, we should go over helix admin [Wed Apr 30 17:37:09 2014] <kishoreg-helix>: figure out how we can write the same functions using command pattern [Wed Apr 30 17:38:10 2014] <osgigeek>: I wont jump to conclusions but from this conversation it appears your (you guys) experience tells you the commands may get too verbose for existing APIs. From what I recall of the HelixAdmin it has very fine grained APIs which is brittle [Wed Apr 30 17:38:50 2014] <osgigeek>: A query can be a command too but what I am hearing is that command pattern needs to be scalable [Wed Apr 30 17:39:08 2014] <osgigeek>: so for future attributes/entities we add we should be able to query without changes to APIs too much [Wed Apr 30 17:39:20 2014] <kishoreg-helix>: we are just telling you the problems, we really dont know the solution :) [Wed Apr 30 17:39:29 2014] <osgigeek>: no worries [Wed Apr 30 17:39:34 2014] <osgigeek>: I understand that [Wed Apr 30 17:39:37 2014] <kishoreg-helix>: its the problem with existing 0.6 and 0.7 [Wed Apr 30 17:39:43 2014] <osgigeek>: yes I understand [Wed Apr 30 17:39:49 2014] <kishoreg-helix>: your new api's might have actually solved it [Wed Apr 30 17:40:02 2014] <kishoreg-helix>: we probably need to see it to believe it [Wed Apr 30 17:40:05 2014] <osgigeek>: yes [Wed Apr 30 17:40:14 2014] <kishoreg-helix>: so if we just take helixadmin [Wed Apr 30 17:40:25 2014] <kishoreg-helix>: implement each function using new api [Wed Apr 30 17:40:37 2014] <kishoreg-helix>: that would put an end to this discussion [Wed Apr 30 17:40:51 2014] <kishoreg-helix>: kanakb: do u think thats a worth while exercise? [Wed Apr 30 17:40:53 2014] <osgigeek>: I am worried we might be short sighted with that approach [Wed Apr 30 17:41:19 2014] <kishoreg-helix>: but do u agree its a neccessary excercise [Wed Apr 30 17:41:31 2014] <kishoreg-helix>: may be not sufficient to prove that its scalable [Wed Apr 30 17:41:46 2014] <kanakb>: i think that's useful [Wed Apr 30 17:41:48 2014] <kishoreg-helix>: buts its like a minimal requirement [Wed Apr 30 17:42:45 2014] <kishoreg-helix>: lets move on to next items, revisit this [Wed Apr 30 17:42:52 2014] <kishoreg-helix>: it is completely orthogonal [Wed Apr 30 17:42:56 2014] <osgigeek>: yes I agree its a minimal requirement, which is why I was saying early on and in response to kanakb: that it is my next item [Wed Apr 30 17:43:04 2014] <kishoreg-helix>: ok [Wed Apr 30 17:43:13 2014] <kishoreg-helix>: i like the connection part [Wed Apr 30 17:43:56 2014] <osgigeek>: glad someone likes something :P [Wed Apr 30 17:44:16 2014] <kishoreg-helix>: though i have some feedback on names [Wed Apr 30 17:44:20 2014] <kishoreg-helix>: ;-) [Wed Apr 30 17:44:53 2014] <kishoreg-helix>: dont know if names convey the functionality [Wed Apr 30 17:45:02 2014] <kishoreg-helix>: write and read [Wed Apr 30 17:45:23 2014] <osgigeek>: sure send them over [Wed Apr 30 17:45:28 2014] <osgigeek>: nothing is sacred [Wed Apr 30 17:45:30 2014] <kishoreg-helix>: HelixClient is read only rt [Wed Apr 30 17:45:33 2014] <osgigeek>: yes [Wed Apr 30 17:45:46 2014] <kishoreg-helix>: not sure if the name conveys that [Wed Apr 30 17:46:13 2014] <kishoreg-helix>: i like HelixClient name [Wed Apr 30 17:46:22 2014] <kishoreg-helix>: and probably want that to be default [Wed Apr 30 17:46:29 2014] <kishoreg-helix>: than helixadministratorclient [Wed Apr 30 17:47:06 2014] <osgigeek>: So there is a concept of role here [Wed Apr 30 17:48:15 2014] <kishoreg-helix>: probably i thinking one step ahead here, i am guessing the role classes participantservice, controllerservice will have a reference to this ***Client [Wed Apr 30 17:48:54 2014] <osgigeek>: yes correct [Wed Apr 30 17:49:08 2014] <osgigeek>: so the reason for the separation was to have write and read separation [Wed Apr 30 17:50:12 2014] <kishoreg-helix>: i see that as a nice to have v/s must have [Wed Apr 30 17:50:32 2014] <kishoreg-helix>: i haven't seen a use case where we need only one [Wed Apr 30 17:50:33 2014] <osgigeek>: then there is no reason to separate them [Wed Apr 30 17:50:49 2014] <osgigeek>: I think that is what you are saying [Wed Apr 30 17:50:57 2014] <kishoreg-helix>: it might be useful in dashboards we provide [Wed Apr 30 17:51:08 2014] <osgigeek>: my thought was when you do an admin dashboard [Wed Apr 30 17:51:11 2014] <osgigeek>: or a monitoring console [Wed Apr 30 17:51:22 2014] <osgigeek>: there is a separation [Wed Apr 30 17:51:26 2014] <osgigeek>: monitoring -> HelixClient [Wed Apr 30 17:51:32 2014] <osgigeek>: Admin Dashboard -> Admin [Wed Apr 30 17:52:16 2014] <kishoreg-helix>: i would do [Wed Apr 30 17:52:24 2014] <kishoreg-helix>: HelixClient -> read and write [Wed Apr 30 17:53:17 2014] <osgigeek>: sure [Wed Apr 30 17:53:26 2014] <kishoreg-helix>: HelixReadOnlyClient [Wed Apr 30 17:53:36 2014] <osgigeek>: no lets not do that [Wed Apr 30 17:53:46 2014] <kishoreg-helix>: or client.setReadOnly [Wed Apr 30 17:54:02 2014] <osgigeek>: First question is do we need that separation [Wed Apr 30 17:54:10 2014] <kishoreg-helix>: not really [Wed Apr 30 17:54:18 2014] <osgigeek>: then lets do one class [Wed Apr 30 17:54:20 2014] <osgigeek>: HelixClient [Wed Apr 30 17:54:23 2014] <osgigeek>: and that's that [Wed Apr 30 17:54:37 2014] <kishoreg-helix>: ok [Wed Apr 30 17:54:45 2014] <kishoreg-helix>: kanakb what do you think ? [Wed Apr 30 17:55:01 2014] <kanakb>: makes sense to me [Wed Apr 30 17:55:11 2014] <kishoreg-helix>: zzhang: ? [Wed Apr 30 17:55:13 2014] <kanakb>: i prefer shorter names for things that appear everywhere [Wed Apr 30 17:55:24 2014] <kanakb>: so in that sense it sounds good [Wed Apr 30 17:57:21 2014] <kishoreg-helix>: ok, [Wed Apr 30 17:57:35 2014] <kishoreg-helix>: this is my preference order [Wed Apr 30 17:57:43 2014] <kishoreg-helix>: helixadminclient â> helixclient [Wed Apr 30 17:58:01 2014] <kishoreg-helix>: helixclient â> can be renamed to anything that conveys its read only [Wed Apr 30 17:58:19 2014] <osgigeek>: Here is my suggestion [Wed Apr 30 17:58:23 2014] <kishoreg-helix>: helixquery [Wed Apr 30 17:58:31 2014] <osgigeek>: HelixClient has HelixAdmin APIs [Wed Apr 30 17:58:39 2014] <osgigeek>: and we have one client [Wed Apr 30 17:59:17 2014] <kishoreg-helix>: ok [Wed Apr 30 17:59:22 2014] <osgigeek>: I think anything with find(HelixQuery) [Wed Apr 30 17:59:34 2014] <osgigeek>: sorry I meant anything with find semantics takes HelixQuery [Wed Apr 30 18:03:15 2014] <kishoreg-helix>: ok [Wed Apr 30 18:03:33 2014] <kishoreg-helix>: so we just have one class? [Wed Apr 30 18:03:36 2014] <kishoreg-helix>: helixclient [Wed Apr 30 18:03:49 2014] <osgigeek>: yes simple enough I think [Wed Apr 30 18:03:51 2014] <kishoreg-helix>: ok [Wed Apr 30 18:03:56 2014] <kishoreg-helix>: whats the next topic [Wed Apr 30 18:04:01 2014] <osgigeek>: Rebalancers [Wed Apr 30 18:04:22 2014] <osgigeek>: we want them in APIs I imagine question is do you want it in the first cut? [Wed Apr 30 18:04:27 2014] <osgigeek>: we could add them in later [Wed Apr 30 18:04:35 2014] <osgigeek>: i.e. we dont have to have the API all fleshed out [Wed Apr 30 18:04:40 2014] <osgigeek>: we can always add, but we cannot remove [Wed Apr 30 18:06:18 2014] <kishoreg-helix>: lets atleast walk through how it will look [Wed Apr 30 18:06:41 2014] <kishoreg-helix>: i want the rebalancer to be just a reference in the resource [Wed Apr 30 18:06:49 2014] <kishoreg-helix>: mixing rebalancerconfig and resourceconfig is bad [Wed Apr 30 18:07:02 2014] <kishoreg-helix>: which is what we have right now [Wed Apr 30 18:07:15 2014] <kishoreg-helix>: we need the concept of ResourceType [Wed Apr 30 18:07:33 2014] <kishoreg-helix>: and we will add different ResourceType [Wed Apr 30 18:07:39 2014] <kishoreg-helix>: PartitionedResource [Wed Apr 30 18:07:47 2014] <kishoreg-helix>: PartitionedReplicatedResource [Wed Apr 30 18:08:00 2014] <kishoreg-helix>: Service, task [Wed Apr 30 18:08:06 2014] <kanakb>: we need to think about this a little bit [Wed Apr 30 18:08:18 2014] <kanakb>: if we're not careful, it will make all existing use cases more difficult to implement [Wed Apr 30 18:08:26 2014] <kishoreg-helix>: agree [Wed Apr 30 18:08:59 2014] <osgigeek>: I hear careful, more thought which means punt on it for now :D [Wed Apr 30 18:09:39 2014] <kanakb>: i think it means more like "don't worry about the details, but keep it in mind so that we're not stuck later" [Wed Apr 30 18:10:01 2014] <kanakb>: but yeah we can discuss [Wed Apr 30 18:10:07 2014] <kanakb>: this can come up in code review [Wed Apr 30 18:10:22 2014] <osgigeek>: so if we need more thought in it, what are we adding to API? [Wed Apr 30 18:10:29 2014] <osgigeek>: I'd rather not add something which is not thought out [Wed Apr 30 18:10:42 2014] <osgigeek>: breaking APIs should be a last resort [Wed Apr 30 18:10:48 2014] <kanakb>: yeah [Wed Apr 30 18:10:49 2014] <kishoreg-helix>: this is the problem statement [Wed Apr 30 18:11:10 2014] <kishoreg-helix>: we will have some interfaces [Wed Apr 30 18:11:24 2014] <kishoreg-helix>: which will have impl classes and implConfig classes [Wed Apr 30 18:11:48 2014] <kishoreg-helix>: we need a pattern for such use cases [Wed Apr 30 18:12:25 2014] <kishoreg-helix>: we can say we have IXYZ and IXYZConfig [Wed Apr 30 18:12:34 2014] <kishoreg-helix>: and XYZ, XYZConfig [Wed Apr 30 18:12:38 2014] <osgigeek>: by pattern you mean naming convention [Wed Apr 30 18:12:48 2014] <osgigeek>: not as in design pattern [Wed Apr 30 18:13:29 2014] <kishoreg-helix>: correct [Wed Apr 30 18:13:45 2014] <kishoreg-helix>: sorry [Wed Apr 30 18:13:55 2014] <kishoreg-helix>: i mean how to dsign pattern [Wed Apr 30 18:14:13 2014] <kishoreg-helix>: as in where will I* classes live ( possibly in API) [Wed Apr 30 18:14:21 2014] <kishoreg-helix>: and impl classes [Wed Apr 30 18:14:26 2014] <kishoreg-helix>: possibly in core [Wed Apr 30 18:14:49 2014] <osgigeek>: I prefer not to have 'I' something [Wed Apr 30 18:15:03 2014] <osgigeek>: We should have XYZ and XYZImpl [Wed Apr 30 18:15:25 2014] <osgigeek>: what does 'I' indicate? [Wed Apr 30 18:16:19 2014] <kishoreg-helix>: i dont prefer I, i am just using it to indicate its an interface or abstract class [Wed Apr 30 18:17:34 2014] <osgigeek>: not a big fan of leaking class type in the name [Wed Apr 30 18:17:46 2014] <osgigeek>: Atleast not for interfaces [Wed Apr 30 18:17:55 2014] <osgigeek>: if we need we can say AbstractXYZ [Wed Apr 30 18:18:09 2014] <osgigeek>: or XYZInterface [Wed Apr 30 18:18:30 2014] <osgigeek>: not a big fan of I [Wed Apr 30 18:19:38 2014] <kishoreg-helix>: i think i confused using I, as I mentioned not particular about the naming [Wed Apr 30 18:19:56 2014] <osgigeek>: ok so you wanted a naming convention [Wed Apr 30 18:20:02 2014] <kishoreg-helix>: no [Wed Apr 30 18:20:16 2014] <kishoreg-helix>: let me take a concrete example [Wed Apr 30 18:20:21 2014] <kishoreg-helix>: we have autorebalancer [Wed Apr 30 18:20:26 2014] <kishoreg-helix>: and autorebalancerconfig [Wed Apr 30 18:21:13 2014] <kishoreg-helix>: we will have many such rebalancers [Wed Apr 30 18:21:23 2014] <kishoreg-helix>: and each rebalancer will have a config class [Wed Apr 30 18:21:49 2014] <osgigeek>: so its XYZ and XYZConfiguration where XYZ indicates algorithm, strategy or whatever which defines the behavior [Wed Apr 30 18:22:22 2014] <kishoreg-helix>: yes [Wed Apr 30 18:22:47 2014] <osgigeek>: so you just want that formalized and consistenly applied [Wed Apr 30 18:22:54 2014] <osgigeek>: consistently [Wed Apr 30 18:23:29 2014] <kishoreg-helix>: yes [Wed Apr 30 18:23:37 2014] <osgigeek>: ok so I will make a start [Wed Apr 30 18:23:41 2014] <osgigeek>: in the APIs [Wed Apr 30 18:23:44 2014] <osgigeek>: we will document it [Wed Apr 30 18:23:45 2014] <kishoreg-helix>: my guess is XYZConfiguration will be in API [Wed Apr 30 18:23:53 2014] <osgigeek>: and then enforce it through reviews [Wed Apr 30 18:23:59 2014] <kishoreg-helix>: and XYZ actual algorithm will be in core [Wed Apr 30 18:24:25 2014] <kishoreg-helix>: kanakb: does it make sense [Wed Apr 30 18:25:06 2014] <kanakb>: yeah it makes sense [Wed Apr 30 18:25:08 2014] <osgigeek>: intuitively I think we need something like an interface for XYZ in APIâ¦because there is configuration and access to the algorithm [Wed Apr 30 18:25:34 2014] <osgigeek>: albeit a read only interface [Wed Apr 30 18:25:44 2014] <osgigeek>: the impl for the algorithm stays in core [Wed Apr 30 18:25:55 2014] <kishoreg-helix>: so AutoRebalancer interface in API [Wed Apr 30 18:26:03 2014] <kishoreg-helix>: AutoRebalancerImpl in core? [Wed Apr 30 18:26:26 2014] <kishoreg-helix>: and AutoRebalancerConfig in API ? [Wed Apr 30 18:26:27 2014] <kanakb>: does that mean we have a base rebalancer interface and an autorebalancer interface that extends it? [Wed Apr 30 18:26:27 2014] <osgigeek>: i.e. if you see a need to surface anything from the impl to the user [Wed Apr 30 18:27:13 2014] <kishoreg-helix>: i think what ever we need to surface must be in config [Wed Apr 30 18:27:20 2014] <kishoreg-helix>: thats why the separation [Wed Apr 30 18:27:31 2014] <kanakb>: so i'm not clear why we need an interface for each rebalancer type [Wed Apr 30 18:27:37 2014] <kanakb>: rather than a single rebalancer interface [Wed Apr 30 18:27:40 2014] <osgigeek>: then we dont need an interface [Wed Apr 30 18:27:47 2014] <osgigeek>: we only have config in API [Wed Apr 30 18:27:54 2014] <kishoreg-helix>: ok [Wed Apr 30 18:28:08 2014] <osgigeek>: mind you we have entity and entityconfig for core model entities today [Wed Apr 30 18:28:14 2014] <osgigeek>: does that need to change? [Wed Apr 30 18:28:18 2014] <kishoreg-helix>: nope [Wed Apr 30 18:28:31 2014] <osgigeek>: ok so we are breaking the pattern here for rebalancers [Wed Apr 30 18:28:50 2014] <kanakb>: rebalancers should probably be something like state model definitions [Wed Apr 30 18:29:09 2014] <kanakb>: globally available, referrable by individual resources [Wed Apr 30 18:29:31 2014] <kanakb>: it's just that they're a little more complicated in that [Wed Apr 30 18:29:41 2014] <kanakb>: there's a concrete class that needs to be called [Wed Apr 30 18:29:48 2014] <kanakb>: and a configuration corresponding to that class [Wed Apr 30 18:30:47 2014] <osgigeek>: ok sounds like we will have a few iterations on this one, but I get the gist [Wed Apr 30 18:31:29 2014] <kanakb>: ok, anything else that we need to cover? [Wed Apr 30 18:31:43 2014] <osgigeek>: I need to hang up soon [Wed Apr 30 18:31:55 2014] <osgigeek>: so I dont have anything [Wed Apr 30 18:31:57 2014] <kanakb>: ok [Wed Apr 30 18:31:59 2014] <osgigeek>: I have my work cut out [Wed Apr 30 18:32:02 2014] <osgigeek>: but please review [Wed Apr 30 18:32:06 2014] <kanakb>: sure [Wed Apr 30 18:32:07 2014] <osgigeek>: as and when I have stuff available [Wed Apr 30 18:32:09 2014] <osgigeek>: thx [Wed Apr 30 18:32:12 2014] <kishoreg-helix>: thanks, we shud start dividng [Wed Apr 30 18:32:13 2014] <kanakb>: thank you [Wed Apr 30 18:32:23 2014] <osgigeek>: oh one more thing [Wed Apr 30 18:32:26 2014] <osgigeek>: we were planning to meet [Wed Apr 30 18:32:28 2014] <osgigeek>: 1/2 day [Wed Apr 30 18:32:40 2014] <kishoreg-helix>: yes, kanak is leaving tomorrow. [Wed Apr 30 18:32:41 2014] <osgigeek>: when [Wed Apr 30 18:32:42 2014] <kanakb>: i'm gonna be out of country start tomorrow evening [Wed Apr 30 18:32:44 2014] <osgigeek>: oh [Wed Apr 30 18:32:50 2014] <kishoreg-helix>: if you can make it tomorrow that will be awesome [Wed Apr 30 18:33:00 2014] <osgigeek>: tomorrow morning [Wed Apr 30 18:33:03 2014] <osgigeek>: I will check [Wed Apr 30 18:33:03 2014] <kishoreg-helix>: ok [Wed Apr 30 18:33:07 2014] <osgigeek>: let me confirm [Wed Apr 30 18:33:11 2014] <osgigeek>: will send out a mail [Wed Apr 30 18:33:13 2014] <kishoreg-helix>: ok, sounds good [Wed Apr 30 18:33:17 2014] <osgigeek>: thx [Wed Apr 30 18:33:30 2014] <kanakb>: ok let's wrap up the meeting [Wed Apr 30 18:33:38 2014] <kanakb>: thanks guys [Wed Apr 30 18:33:42 2014] <kanakb>: ASFBot: meeting end Meeting ended at Wed Apr 30 18:33:42 2014
