+1.
On Thu, Feb 27, 2014 at 4:15 PM, Kanak Biscuitwala <[email protected]>wrote: > Sure, let's do meetings every week, where morning/evening alternate. We > can also schedule additional meetings if things are unresolved. > > So next Wednesday, let's have a 10am PT meeting, and then the following > Wednesday we can have a 10pm PT meeting (and so on). Does that sound > reasonable? > > ---------------------------------------- > > Date: Thu, 27 Feb 2014 15:10:13 -0800 > > Subject: Re: Summary of IRC Meeting in #apachehelix > > From: [email protected] > > To: [email protected] > > > > Hi Kanak, > > > > I am new with Helix and just start playing around to get better grasp > > on how it works (got some help from Kishore along the way). > > > > I think regularly scheduled chat sessions are useful for newbies to > > stop by and ask questions or start discussions. > > We had it in Apache Shindig for a while and especially near release > > candidate generation. > > > > Not all people could attend due to the distributed nature of > > contributors so if it is going to have some IRC chat sessions maybe > > alternately done early morning and evening PST to accommodate most > > time zones. > > > > > > - Henry > > > > > > On Thu, Feb 27, 2014 at 1:22 PM, Kanak Biscuitwala <[email protected]> > wrote: > >> > >> Hi Henry, > >> > >> We don't currently have scheduled meetings -- this one just happened > ad-hoc. Do you think this is useful/valuable? If so, what frequency do you > think makes sense? > >> > >> Other devs: same question. > >> > >> Kanak > >> > >> > >> ---------------------------------------- > >>> Date: Thu, 27 Feb 2014 13:16:35 -0800 > >>> Subject: Re: Summary of IRC Meeting in #apachehelix > >>> From: [email protected] > >>> To: [email protected] > >>> > >>> Hi Guys, > >>> > >>> Do you guys do this (IIRC chat) every Wednesdays? > >>> > >>> - Henry > >>> > >>> On Tue, Feb 25, 2014 at 11:16 PM, ASF IRC Bot > >>> <[email protected]> wrote: > >>>> Summary of IRC Meeting in #apachehelix at Wed Feb 26 05:50:29 2014: > >>>> > >>>> Attendees: zzhang1, gmcdonald, osgigeek1, kanakb, kishoreg1 > >>>> > >>>> - Preface > >>>> > >>>> > >>>> IRC log follows: > >>>> > >>>> ## Preface ## > >>>> [Wed Feb 26 05:50:35 2014] <gmcdonald>: cool > >>>> [Wed Feb 26 05:50:38 2014] <kanakb>: sweet > >>>> [Wed Feb 26 05:50:44 2014] <gmcdonald>: Im outta here, enjoy > >>>> [Wed Feb 26 05:51:23 2014] <kanakb>: okay anyway > >>>> [Wed Feb 26 05:51:43 2014] <kanakb>: i think we can use the pattern > that osgigeek1 suggested > >>>> [Wed Feb 26 05:52:07 2014] <kanakb>: i.e. > >>>> [Wed Feb 26 05:52:21 2014] <kanakb>: new > HelixAdministratorBuilder.usingProvider(HelixStoreProvider.ZOOKEEPER).toAddress(zkAddress).build(); > >>>> [Wed Feb 26 05:52:37 2014] <kanakb>: and > >>>> [Wed Feb 26 05:53:00 2014] <kanakb>: new > HelixAdministratorBuilder.usingProvider(HelixStoreProvider.MYDB).username(username).host(hostname).build() > >>>> [Wed Feb 26 05:54:19 2014] <kishoreg1>: looks good, > >>>> [Wed Feb 26 05:54:50 2014] <kishoreg1>: Sandeep, is Provider the > right term ? > >>>> [Wed Feb 26 05:55:00 2014] <osgigeek1>: yes provider is the right > term here > >>>> [Wed Feb 26 05:55:30 2014] <kishoreg1>: ok, sounds good > >>>> [Wed Feb 26 05:55:52 2014] <osgigeek1>: ok so we now have an instance > of HelixAdmin > >>>> [Wed Feb 26 05:55:59 2014] <kanakb>: ok now how does a participant > get an admin? > >>>> [Wed Feb 26 05:56:16 2014] <kanakb>: participant.getAdmin()? > >>>> [Wed Feb 26 05:56:22 2014] <kanakb>: spectator.getAdmin()? > >>>> [Wed Feb 26 05:57:05 2014] <kanakb>: or it could even be a getter > within the service class if we go that direction > >>>> [Wed Feb 26 05:57:58 2014] <kanakb>: but i guess we can come back to > that > >>>> [Wed Feb 26 05:58:01 2014] <osgigeek1>: so before we go to > participant should we capture what APIs hang off the HelixAdmin or > HelixAdministrator? > >>>> [Wed Feb 26 05:58:07 2014] <kanakb>: yeah sure > >>>> [Wed Feb 26 05:58:43 2014] <kishoreg1>: we have two options > >>>> [Wed Feb 26 05:58:59 2014] <kishoreg1>: #1. flat methods similar to > what we have > >>>> [Wed Feb 26 05:59:49 2014] <kishoreg1>: create/delete/update/read > cluster|resource|instance| etc > >>>> [Wed Feb 26 06:00:33 2014] <kishoreg1>: there will be too many > methods in this > >>>> [Wed Feb 26 06:00:54 2014] <kishoreg1>: #2. heirarchical based on > scope > >>>> [Wed Feb 26 06:01:04 2014] <kishoreg1>: based on scope/entity > >>>> [Wed Feb 26 06:01:26 2014] <kishoreg1>: clusteradmin resourceadmin > instanceadmin > >>>> [Wed Feb 26 06:01:44 2014] <osgigeek1>: I prefer #1 > >>>> [Wed Feb 26 06:02:37 2014] <kishoreg1>: how many methods do we think > we will have in this interface > >>>> [Wed Feb 26 06:02:40 2014] <kishoreg1>: 100? > >>>> [Wed Feb 26 06:02:59 2014] <kanakb>: probably 50 > >>>> [Wed Feb 26 06:03:07 2014] <kanakb>: there are some things we can > consolidate > >>>> [Wed Feb 26 06:03:10 2014] <kishoreg1>: ok > >>>> [Wed Feb 26 06:03:20 2014] <kanakb>: e.g. the things that involve > userconfig > >>>> [Wed Feb 26 06:03:25 2014] <kanakb>: those can take scope as a > parameter > >>>> [Wed Feb 26 06:03:55 2014] <kishoreg1>: sandeep, you should look at > the api's in the current helixadmin > >>>> [Wed Feb 26 06:03:57 2014] <osgigeek1>: so why do we think it will be > 50? > >>>> [Wed Feb 26 06:04:20 2014] <kanakb>: the current number of helixadmin > method calls is like 20-30 > >>>> [Wed Feb 26 06:04:20 2014] <osgigeek1>: looking at it now > >>>> [Wed Feb 26 06:04:31 2014] <kanakb>: so say it doubles because we > cover more use cases > >>>> [Wed Feb 26 06:04:34 2014] <kanakb>: then it's 50 > >>>> [Wed Feb 26 06:04:43 2014] <kishoreg1>: there are too many > combinations i think, we need to figure out how to reduce this > >>>> [Wed Feb 26 06:05:33 2014] <osgigeek1>: Can we consider like a > command pattern? > >>>> [Wed Feb 26 06:05:48 2014] <osgigeek1>: like I see several > addResource(param....) > >>>> [Wed Feb 26 06:05:58 2014] <osgigeek1>: instead how about > addResource(ResourceCommand) > >>>> [Wed Feb 26 06:06:15 2014] <kishoreg1>: i like that > >>>> [Wed Feb 26 06:06:16 2014] <osgigeek1>: the command encapsulates the > different params > >>>> [Wed Feb 26 06:06:24 2014] <osgigeek1>: that way we can decipher from > the command > >>>> [Wed Feb 26 06:06:40 2014] <kanakb>: well, if we're adding using > ResourceConfig like in the wiki, then is this still necessary? > >>>> [Wed Feb 26 06:08:14 2014] <kishoreg1>: probably yes, > >>>> [Wed Feb 26 06:08:28 2014] <kishoreg1>: lets say we want to only > update provisionerconfig > >>>> [Wed Feb 26 06:08:36 2014] <kishoreg1>: we have two options delta > >>>> [Wed Feb 26 06:12:01 2014] <osgigeek1>: So kanakb I think if command > == config and that was the notion then we can go with config > >>>> [Wed Feb 26 06:12:31 2014] <osgigeek1>: but it appears kishoreg1 is > pointing to the something missing > >>>> [Wed Feb 26 06:13:11 2014] <kishoreg1>: its along the same line but > its too generic > >>>> [Wed Feb 26 06:13:30 2014] <kishoreg1>: There is only one > ResourceCommand > >>>> [Wed Feb 26 06:14:03 2014] <kanakb>: are you suggesting something like > >>>> [Wed Feb 26 06:14:14 2014] <kanakb>: administrateResource(command, > args) > >>>> [Wed Feb 26 06:14:17 2014] <kanakb>: or something to that effect? > >>>> [Wed Feb 26 06:14:33 2014] <kishoreg1>: nope > >>>> [Wed Feb 26 06:15:15 2014] <kishoreg1>: currently we have > updateResource(ResourceCommand) > >>>> [Wed Feb 26 06:16:07 2014] <kishoreg1>: but the usecases are updating > partitions, replicas, rebalancerconfig, provisionerconfig etc > >>>> [Wed Feb 26 06:19:37 2014] <kishoreg1>: > https://github.com/apache/helix/blob/master/helix-core/src/main/java/org/apache/helix/HelixAdmin.java > >>>> [Wed Feb 26 06:22:11 2014] <kishoreg1>: what do u guys think > >>>> [Wed Feb 26 06:23:15 2014] <osgigeek1>: I did not quite follow the > part where kishoreg1 you point to updating partitions, replicas, > rebalancerconfig etc can you elaborate? > >>>> [Wed Feb 26 06:23:59 2014] <kishoreg1>: after the resource is created > >>>> [Wed Feb 26 06:24:42 2014] <kishoreg1>: we might have to update some > parts of the resources, for example change the number of partitions from 10 > to 20 > >>>> [Wed Feb 26 06:24:46 2014] <osgigeek1>: ah gotcha > >>>> [Wed Feb 26 06:24:50 2014] <kishoreg1>: we have two options > >>>> [Wed Feb 26 06:25:17 2014] <kishoreg1>: have a method called > updateParitionNumber(resourceId, numberof partitions) > >>>> [Wed Feb 26 06:25:30 2014] <kishoreg1>: or > updateResource(ResourceConfig) > >>>> [Wed Feb 26 06:25:45 2014] <kishoreg1>: > updateResource(ResourceConfig.Delta) > >>>> [Wed Feb 26 06:25:51 2014] <osgigeek1>: now I follow > >>>> [Wed Feb 26 06:25:54 2014] <kishoreg1>: ok > >>>> [Wed Feb 26 06:26:18 2014] <kishoreg1>: so if we just have one method > for all operations, its too overloaded > >>>> [Wed Feb 26 06:28:34 2014] <osgigeek1>: ok so lets look at the > primary entities here > >>>> [Wed Feb 26 06:29:01 2014] <osgigeek1>: (1) cluster (2) resource (3) > instance > >>>> [Wed Feb 26 06:29:04 2014] <osgigeek1>: am I correct? > >>>> [Wed Feb 26 06:29:25 2014] <kanakb>: arguably partition > >>>> [Wed Feb 26 06:29:33 2014] <osgigeek1>: ok so 4 > >>>> [Wed Feb 26 06:30:07 2014] <osgigeek1>: so what if we think of having > CRUD operations for those through commands on the HelixAdmin > >>>> [Wed Feb 26 06:30:42 2014] <osgigeek1>: everything else which is not > a primary entity lets say we model on the Command or as a derived object > off the correct Command? > >>>> [Wed Feb 26 06:31:26 2014] <kishoreg1>: others I can think of are > adding statemodel, constraints etc > >>>> [Wed Feb 26 06:31:29 2014] <osgigeek1>: e.g. ResourceCommand, > ResourceReplicaCommand extends ResourceCommand? or should the > ResourceCommand have Replica as a composite ? > >>>> [Wed Feb 26 06:31:59 2014] <kishoreg1>: hmm thinking > >>>> [Wed Feb 26 06:32:11 2014] <osgigeek1>: I am thinking of statemodel, > constraints all as parts that can be attached to the primary entities > >>>> [Wed Feb 26 06:32:25 2014] <osgigeek1>: arguably not attacheable to > all but most I imagine > >>>> [Wed Feb 26 06:32:30 2014] <kishoreg1>: yes > >>>> [Wed Feb 26 06:33:10 2014] <kishoreg1>: why should it extend > resourcecommand > >>>> [Wed Feb 26 06:34:02 2014] <osgigeek1>: on a second thought no lets > not extend it, the more I think the more little sense it makes > >>>> [Wed Feb 26 06:34:19 2014] <osgigeek1>: I think this is what kanakb > modelled in his wiki > >>>> [Wed Feb 26 06:34:33 2014] <osgigeek1>: a builder which allows > attaching the composites into one command > >>>> [Wed Feb 26 06:34:39 2014] <osgigeek1>: or in his case config > >>>> [Wed Feb 26 06:35:26 2014] <osgigeek1>: So we have a command builder > >>>> [Wed Feb 26 06:35:48 2014] <osgigeek1>: > ResourceCommandBuilder().usingStateModel().withConstraints().build() > >>>> [Wed Feb 26 06:36:03 2014] <osgigeek1>: > InstanceCommandBuilder().withConstraints().build() > >>>> [Wed Feb 26 06:36:30 2014] <kishoreg1>: hmm > >>>> [Wed Feb 26 06:36:56 2014] <osgigeek1>: so the key thing I am after > is separating the primary entities > >>>> [Wed Feb 26 06:37:01 2014] <osgigeek1>: and calling them out at the > top level > >>>> [Wed Feb 26 06:37:10 2014] <kishoreg1>: do we need builder pattern > for commands > >>>> [Wed Feb 26 06:38:57 2014] <osgigeek1>: Lets ask this question a bit > differently > >>>> [Wed Feb 26 06:39:17 2014] <osgigeek1>: how well defined are the > commands, do we think they are pretty well formalized? Do we foresee them > changing ? > >>>> [Wed Feb 26 06:40:01 2014] <zzhang1>: we may add new fields to the > configs > >>>> [Wed Feb 26 06:40:16 2014] <kishoreg1>: they might change but most > likely we will be adding new stuff > >>>> [Wed Feb 26 06:40:33 2014] <kishoreg1>: yeah, agree with jason > >>>> [Wed Feb 26 06:40:42 2014] <osgigeek1>: the new stuff added would > that be in existing buckets of statemodel, constraints? I imagine yes > >>>> [Wed Feb 26 06:41:01 2014] <kishoreg1>: yes, > >>>> [Wed Feb 26 06:41:41 2014] <osgigeek1>: my instinct tells me its > better to hide the command objects and give builders > >>>> [Wed Feb 26 06:41:52 2014] <osgigeek1>: but you guys would be better > judges > >>>> [Wed Feb 26 06:42:29 2014] <osgigeek1>: when I say hide I mean not > give out the setters > >>>> [Wed Feb 26 06:42:30 2014] <kishoreg1>: we can come to builders v/s > concrete after we decide how many command classes we will have > >>>> [Wed Feb 26 06:42:40 2014] <osgigeek1>: yeah lets do that > >>>> [Wed Feb 26 06:43:16 2014] <kishoreg1>: lets take simple cases like > change partition, replica > >>>> [Wed Feb 26 06:43:32 2014] <osgigeek1>: ok > >>>> [Wed Feb 26 06:43:45 2014] <kishoreg1>: or some flags in idealstate > like enable/disable > >>>> [Wed Feb 26 06:44:01 2014] <kanakb>: enable/disable resource? > >>>> [Wed Feb 26 06:44:21 2014] <kishoreg1>: resource, bucketization, > group message mode > >>>> [Wed Feb 26 06:44:24 2014] <kishoreg1>: etc > >>>> [Wed Feb 26 06:44:32 2014] <kanakb>: right > >>>> [Wed Feb 26 06:45:16 2014] <kishoreg1>: so we have these options > >>>> [Wed Feb 26 06:46:07 2014] <kishoreg1>: #1 direct method in > helixadmin admin.updateNumPartitions(resourceId, 20) > >>>> [Wed Feb 26 06:47:06 2014] <kishoreg1>: #2. config delta method, > resource.delta= ..., delta.setpartitions(20), > admin.updateresource(resourcedelta) > >>>> [Wed Feb 26 06:47:33 2014] <zzhang1>: i prefer #2, it saves lots of > admin#methods > >>>> [Wed Feb 26 06:47:45 2014] <osgigeek1>: may I ask this and you will > see where I am going with this... what do we return on > helixAdmin.addResource(ResourceCommand) > >>>> [Wed Feb 26 06:48:04 2014] <osgigeek1>: void? HelixResource? > >>>> [Wed Feb 26 06:48:20 2014] <kishoreg1>: #3. command pattern > UpdatePartitionCommand.updatePartitions(20) admin.updateResource(command); > >>>> [Wed Feb 26 06:48:34 2014] <kishoreg1>: dunno > >>>> [Wed Feb 26 06:48:58 2014] <kishoreg1>: i will be back in 10-15 > minutes > >>>> [Wed Feb 26 06:48:59 2014] <zzhang1>: currently we are returning void > >>>> [Wed Feb 26 06:49:37 2014] <kanakb>: i think it should either: return > boolean or throw a meaningful checked exception > >>>> [Wed Feb 26 06:49:59 2014] <osgigeek1>: so should we return a > HelixResource? > >>>> [Wed Feb 26 06:50:17 2014] <osgigeek1>: rather I meant to ask why not > return a HelixResource? > >>>> [Wed Feb 26 06:51:12 2014] <kanakb>: a resource is a resource config > plus runtime state, like its external view > >>>> [Wed Feb 26 06:51:18 2014] <kanakb>: initially this external view > will always be empty > >>>> [Wed Feb 26 06:51:38 2014] <kanakb>: so it's not super useful to just > return that > >>>> [Wed Feb 26 06:52:24 2014] <kishoreg1>: thats another item, shud we > mix runtime and static info in one class > >>>> [Wed Feb 26 06:52:48 2014] <kishoreg1>: prefer to defer that to a > later stage > >>>> [Wed Feb 26 06:52:51 2014] <osgigeek1>: ok > >>>> [Wed Feb 26 06:53:05 2014] <osgigeek1>: the reason for the question > was > >>>> [Wed Feb 26 06:53:24 2014] <osgigeek1>: if we return the object we > could have ResourceCommand.using(object) > >>>> [Wed Feb 26 06:53:29 2014] <osgigeek1>: that creates an updateCommand > >>>> [Wed Feb 26 06:53:37 2014] <osgigeek1>: which then can carry existing > state > >>>> [Wed Feb 26 06:53:58 2014] <kanakb>: the hope is that you don't need > existing state in order to make an incremental update > >>>> [Wed Feb 26 06:54:34 2014] <osgigeek1>: ok so lets forget that route > for now, lets go back to the 3 options from kishoreg1 > >>>> [Wed Feb 26 06:54:48 2014] <osgigeek1>: I am leaning towards #3 > >>>> [Wed Feb 26 06:55:03 2014] <kanakb>: yeah i like #3 as well > >>>> [Wed Feb 26 06:55:48 2014] <kanakb>: zzhang1: is #3 generic enough to > support things like monitoring config? > >>>> [Wed Feb 26 06:55:52 2014] <kanakb>: my intuition is yes > >>>> [Wed Feb 26 06:55:59 2014] <zzhang1>: yea > >>>> [Wed Feb 26 06:56:49 2014] <zzhang1>: for #3, shall we have a command > pattern for updating each field? > >>>> [Wed Feb 26 06:57:34 2014] <kishoreg1>: what ever makes sense > >>>> [Wed Feb 26 06:57:51 2014] <osgigeek1>: zzhang1: I think yes that way > we remove APIs like setResourceIdealState from the HelixAdmin > >>>> [Wed Feb 26 06:57:52 2014] <zzhang1>: ok > >>>> [Wed Feb 26 06:58:03 2014] <kanakb>: can we do something like > updateResource(ResourceCommand... commands)? > >>>> [Wed Feb 26 06:58:25 2014] <kishoreg1>: compositecommands? > >>>> [Wed Feb 26 06:58:28 2014] <osgigeek1>: ooh, multiple commands you > mean? > >>>> [Wed Feb 26 06:58:47 2014] <kanakb>: yeah or a composite command > >>>> [Wed Feb 26 06:58:57 2014] <osgigeek1>: I think we dont do that for > the first iteration > >>>> [Wed Feb 26 06:59:08 2014] <kanakb>: i would imagine that there are > certain configs that we'd like to set together as an atomic unit > >>>> [Wed Feb 26 06:59:19 2014] <osgigeek1>: what happens if some commands > fail and some succeed > >>>> [Wed Feb 26 06:59:20 2014] <kishoreg1>: yeah i was thinking the same > >>>> [Wed Feb 26 06:59:31 2014] <kishoreg1>: same as kanakb > >>>> [Wed Feb 26 06:59:41 2014] <kishoreg1>: for example if i want to > change both partition and replica > >>>> [Wed Feb 26 06:59:44 2014] <kanakb>: osgigeek1: then they should all > succeed or all fail > >>>> [Wed Feb 26 07:00:03 2014] <kanakb>: and it's our responsibility to > guarantee that > >>>> [Wed Feb 26 07:00:25 2014] <kanakb>: fortunately this is generally > easy to guarantee in the ZK case > >>>> [Wed Feb 26 07:00:38 2014] <kanakb>: as long as things don't span > znodes > >>>> [Wed Feb 26 07:00:58 2014] <osgigeek1>: kanakb: if we can guarantee > that then sure, I was concerned that it might not be possible given the > distributed nature of the system > >>>> [Wed Feb 26 07:01:46 2014] <kanakb>: there is one interesting case > >>>> [Wed Feb 26 07:01:48 2014] <kishoreg1>: kanakb: how can we gaurantee > things that span multiple znodes > >>>> [Wed Feb 26 07:01:58 2014] <kanakb>: we'd need to do a rollback or > something > >>>> [Wed Feb 26 07:02:10 2014] <kanakb>: so maybe it's not so easy > >>>> [Wed Feb 26 07:02:23 2014] <kanakb>: hmm > >>>> [Wed Feb 26 07:02:50 2014] <kanakb>: right now all our admin apis > work on a single znode > >>>> [Wed Feb 26 07:02:56 2014] <kanakb>: but now that won't be true > >>>> [Wed Feb 26 07:03:21 2014] <kishoreg1>: yeah, we have rely on the spi > to make it atomic > >>>> [Wed Feb 26 07:03:44 2014] <kishoreg1>: but we might need composite > commands > >>>> [Wed Feb 26 07:04:01 2014] <kishoreg1>: for example what if we want > to update both partitions and replicas > >>>> [Wed Feb 26 07:04:10 2014] <kanakb>: right > >>>> [Wed Feb 26 07:04:23 2014] <kanakb>: so we either need to allow > multiple commands, or a single command that does multiple things > >>>> [Wed Feb 26 07:04:29 2014] <osgigeek1>: kishoreg1: we should model > that as one command which carries both partition change and replica change > >>>> [Wed Feb 26 07:04:49 2014] <kanakb>: i.e. > ResourceCommand.partitions(10).replicas(3)? > >>>> [Wed Feb 26 07:04:53 2014] <osgigeek1>: yes > >>>> [Wed Feb 26 07:05:19 2014] <zzhang1>: btw, i think commands like > addCluster() will cross multiple znodes > >>>> [Wed Feb 26 07:05:41 2014] <kanakb>: which brings in the atomic api > issues > >>>> [Wed Feb 26 07:06:12 2014] <kishoreg1>: its upto the implementation, > we shud assume all api's are atomic > >>>> [Wed Feb 26 07:06:36 2014] <osgigeek1>: I think we should make that a > principle of the command APIs > >>>> [Wed Feb 26 07:06:36 2014] <kishoreg1>: we can use multitransaction > updates in ZK > >>>> [Wed Feb 26 07:06:52 2014] <kanakb>: are those available in 3.3.x? > >>>> [Wed Feb 26 07:07:09 2014] <kishoreg1>: nope 3.4.5 i think > >>>> [Wed Feb 26 07:07:14 2014] <kishoreg1>: but u already have locks > >>>> [Wed Feb 26 07:07:18 2014] <kanakb>: yeah > >>>> [Wed Feb 26 07:07:21 2014] <kanakb>: i was going to say > >>>> [Wed Feb 26 07:07:27 2014] <kishoreg1>: so its ok to rely on that > >>>> [Wed Feb 26 07:07:44 2014] <kishoreg1>: what u have is better than > multi transactions i think > >>>> [Wed Feb 26 07:08:09 2014] <kanakb>: well yes and no > >>>> [Wed Feb 26 07:08:30 2014] <kishoreg1>: anyhow > ResourceCommand.partitions(1) will return a type of ResourceCommand? > >>>> [Wed Feb 26 07:09:39 2014] <osgigeek1>: yes, the builder should allow > changing any of the facets i.e. partition or replica of the entity i.e. > Resource in this case > >>>> [Wed Feb 26 07:09:47 2014] <kanakb>: chaining probably isn't possible > unless we change it to new ResourceCommand().partitions(1) > >>>> [Wed Feb 26 07:10:26 2014] <kishoreg1>: ok, i am not good at builder > patterns, i hope we dont have too many classes > >>>> [Wed Feb 26 07:10:38 2014] <kanakb>: that would just be 1 class > >>>> [Wed Feb 26 07:10:45 2014] <osgigeek1>: yes > >>>> [Wed Feb 26 07:10:56 2014] <kishoreg1>: ok > >>>> [Wed Feb 26 07:11:07 2014] <osgigeek1>: i.e. agree with kanakb > >>>> [Wed Feb 26 07:11:36 2014] <kishoreg1>: ok > >>>> [Wed Feb 26 07:13:26 2014] <osgigeek1>: ok well I might have to drop > off in a few mins ... do you guys plan to carry on for long? > >>>> [Wed Feb 26 07:13:36 2014] <kanakb>: probably not too long > >>>> [Wed Feb 26 07:13:43 2014] <kishoreg1>: i think we shud take break as > well > >>>> [Wed Feb 26 07:13:44 2014] <kanakb>: at least we have some direction > with admin now > >>>> [Wed Feb 26 07:14:03 2014] <kishoreg1>: lets write the apis for > administrator and see how it looks > >>>> [Wed Feb 26 07:14:13 2014] <kishoreg1>: i need to get going as well > >>>> [Wed Feb 26 07:15:05 2014] <kanakb>: ok let's end here? > >>>> [Wed Feb 26 07:15:10 2014] <osgigeek1>: well this was good, we made > good progress, yeah lets end > >>>> [Wed Feb 26 07:15:37 2014] <kanakb>: ASFBot: meeting end > >>>> > >>>> > >>>> Meeting ended at Wed Feb 26 07:15:37 2014 > >> > >
