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
