Hey guys, I created a package model.constraint and moved the ClusterConstraint, ConstraintItem, ConstraintItemBuilder in there. I moved ConstraintId into model.id since I did not think it was necessary to create a package model.constraint.id for one class.
I also moved ExternalView into model.composite since the way I understand it, it is a composite view across the cluster. All these are subject to discussion and realignment as we go forward but wanted to make sure we get all the elements in api in the relevant packages so we have all the necessary items on the table so we can work to cleanup and moving towards the apis like Helix-Admin. Everything is checked in, it builds. Comments/feedback are welcome. Thanks, Sandeep On Sat, Mar 22, 2014 at 10:26 PM, Sandeep Nayak <[email protected]> wrote: > I am leaning towards #1 it would be cleaner to apply constraints on > the model elements and keep those constraints separated so we can > evolve them independently. > > Sandeep > > On Sat, Mar 22, 2014 at 2:09 PM, kishore g <[email protected]> wrote: >> Hi, >> >> Thanks to Sandeep and Kanak we are getting close to having the new >> helix-api package. >> >> https://github.com/kanakb/helix >> >> Here is the api package >> https://github.com/kanakb/helix/tree/master/helix-api/src/main/java/org/apache/helix/api >> >> Feedback/suggestions? >> >> >> Before we get started working on the roles (administrator, participant, >> controller, spectator), we need to wrap up the constraints api. >> >> At a high level we have state & transition constraints at cluster, >> participant, resource, partition granularity. >> >> We have two options >> >> #1 Have a separate package called constraints and have >> (cluster|participant|resource|partition)Constraint. >> >> #2. Have StateConstraint & TransitionConstraint as attributes in >> (cluster|participant|resource|partition)configuration. >> >> Thoughts. >> >> >> thanks, >> Kishore G
