I think the core of the problem is that we have config classes (e.g.
ClusterConfig, ResourceConfig, ParticipantConfig) and snapshot classes (e.g.
Cluster, Resource, Participant). Another problem is that we made all of those
classes read-only since we wanted to present it that way to user-defined
rebalancers. Consequently, these fall short in other cases.
I propose the following: we get rid of all the snapshot classes, and we make
all the config classes mutable. By making them mutable, we need to define what
it means to update the config when the config corresponds to multiple ZNodes.
it also requires some changes on the controller side to start using
ClusterDataCache again instead of the full snapshot class.
Right now, we can get accessors (e.g. ClusterAccessor, ResourceAccessor, etc)
from HelixConnection, which have read methods for getting the snapshot classes;
these can be changed to get the config classes.
Thoughts?
> Date: Sun, 2 Feb 2014 07:33:48 -0800
> Subject: Refactor config accessor
> From: [email protected]
> To: [email protected]
>
> Accessing config is not intuitive.
>
> we have too many ways to access configuration but none of them are easy.
>
> HelixConnection seems to be the starting point for accessing all
> information.
>
> We have classes like ClusterConfig, ParticipantConfig, ResourceConfig but I
> dont see a way to get them via HelixConnection.
>
> Also ClusterConfig, ParticipantConfig , ResourceConfig seems to encapsulate
> both runtime and static configuration.
>
> Do you think we need to refactor this?
>
> thanks,
> Kishore G
