Will look at it today. On Apr 6, 2014 12:51 PM, "Sandeep Nayak" <[email protected]> wrote:
> Hi all, > > I started working on the commands, starting with the cluster. Given > that the Configuration hierarchy relies on the ZNRecord, I propose the > following approach. > > We have the Admin API take in commands which then return the classes > under api.model. What we can then do is move the configuration back > into the core and split out the SPI parts from it. > > My approach earlier was to use the configurations as return values > from the command calls but I think thats a larger refactor. > > Let me know what you guys think, as a sample I am working on the > ClusterCommand and once I have it working will check it in as an > example. > > Thanks, > > Sandeep > > On Sun, Apr 6, 2014 at 3:36 AM, Sandeep Nayak <[email protected]> wrote: > > Hi guys, > > > > I have added all of the review feedback to the API. Here are the changes > > > > * Removed the rebalancer configuration into configuration. > > * Added Provisioner and TargetProvider configurations. > > * All constructors using ZNRecord is deprecated > > * Added clusterid to memberid and resourceid > > * Removed apis to create generic members from admin > > * Changed all other non-participant APIs to be final and throws > > UnsupportedException as discussed. > > > > I have been unable to move the ZNRecord and ZNRecordDelta and other > > classes from model primarily because that means HelixConfig needs to > > be moved which is currently the base class from most configurations. > > Ideally we have the ZNRecord abstracted through SPI and not in API. > > > > As usual feedback is welcome. > > > > Thanks, > > > > Sandeep >
