Thanks Guys +1 =)
- Henry 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 >>> >
