You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@helix.apache.org by Sandeep Nayak <os...@gmail.com> on 2014/03/31 06:33:56 UTC
Helix Administrator Client and Helix Client strawman checked in
Hey guys,
I checked in a strawman for the helix administrator and helix client
api classes. There are command classes, id classes and model classes
which tie up the two client apis. The idea is mutation is only allowed
by Administrator API, the client API is only used for discovery.
Please take a look and let me know of the structure and composition. I
decided to not go with the composition model as we had discussed i.e.
HelixCluster having APIs for the creation of entities under it as
separation between administrator client and regular clients was
getting clumsy to achieve. So, I decided to switch back to a
HelixAdministrator and HelixClient based approach which worked better.
Here are the highlights
* The api.role package is no longer needed and all its constituents
are represented in the model package.
* The existing contents of the api.client package now seem to be
candidates for spi project (something I plan to start on in parallel
soon). In other words HelixConnection, HelixConnectionBuilder,
HelixConnectionFactory, HelixConnectionFactoryListener seem to be
internal concerns to the implementations of the API.
* If the structure looks good, I will next start on fleshing out the
contents of each of the command classes. I presume there should be
existing code I can get information from so I will start there when I
get a chance. I will need help on the commands, so will ping at the
appropriate time.
* The contents of api.model package like ZNRecord, ZNRecordDelta etc
will move under the implementation in core. I will keep
HelixConfiguration and have configurations derive from it and these
will eventually get translated before storing into the specific
implementation.
As usual this is work in progress but wanted to give early visibility
so feedback, comments are welcome.
Thanks,
Sandeep
Re: Helix Administrator Client and Helix Client strawman checked in
Posted by kishore g <g....@gmail.com>.
Looking good, some feedback about package layout.
Too many classes floating under model. Property related classes will
probably move out once we define spi.
What is HelixEntity and what will it contain.It might be better to move
them under model.entities
why did we remove the roles package and move the classes under model.
rebalancerconfiguration
-- strategy package sounds odd.
-- we need to rethink how rebalancer is configured. It might be better to
pull it out of ResourceConfiguration and make it similar to statemachine,
that is, configure a rebalancer and assign in the resource configuration
simply provide the reference to that resource. This might also make
resourceconfiguration simpler. Not sure of the implications.
-- Similar to rebalancerconfiguration, we will have
targetproviderconfiguration, provisionerconfiguration etc. These are core
components of the controller pipeline and we should come up with some
terminology to represent. These are analogous to channelhandlers in netty
pipeline.
It looks amazing. Another idea is to implement quickstart using only the
api module. Eventually all recipes should be implemented using only the api
package.
thanks,
Kishore G
On Mon, Mar 31, 2014 at 9:34 PM, kishore g <g....@gmail.com> wrote:
> I missed the helixadministratorclient class, cool idea.
> On Mar 31, 2014 8:15 PM, "Sandeep Nayak" <os...@gmail.com> wrote:
>
>> Hi Kishore,
>>
>> Notice that the HelixAdministratorClient extends from the HelixClient,
>> so the idea was that only administrators roles are allowed to mutate
>> the cluster. A regular HelixClient will only be allowed a view into
>> the cluster.If you get an instance of the HelixAdministratorClient you
>> do have access to read and write methods but if you get an instance of
>> the HelixClient you will only be able to read.
>>
>> Now it is true that Helix as such does not have roles, but the way I
>> envision this working is I see the separation being useful for
>> codebases which embed Helix as a cluster management solution to
>> provide the access to the right level of cluster management based on
>> their access controls. The codebase which embeds Helix may have users
>> and roles which will require access to the separate APIs based on the
>> access controls for the role the user belongs to thus allowing use of
>> Admin or non-Admin capability.
>>
>> Yes, we can take the LogicalModelExample and rewrite it. Let me get
>> all Kanak and your feedback incorporated and checkin another cut
>> tonight based on all the feedback and then I want to add the remaining
>> pieces to the API before we move to rewriting the sample.
>>
>> Thanks,
>>
>> Sandeep
>>
>> On Mon, Mar 31, 2014 at 3:34 PM, kishore g <g....@gmail.com> wrote:
>> > This is looking great. What is the idea behind splitting client (read
>> only)
>> > and admin (write). I like the separation but not sure what is the
>> > motivation. For example, most mutations will involve reading and
>> writing.
>> > Do you think it might cause confusion if we have to use client to read
>> and
>> > admin to write?
>> >
>> > Will it make sense to take the LogicalModelExample and re-write them
>> using
>> > these api's.
>> >
>> > thanks,
>> > Kishore G
>> >
>> >
>> > On Mon, Mar 31, 2014 at 3:16 PM, Kanak Biscuitwala <kanak.b@hotmail.com
>> >wrote:
>> >
>> >>
>> >> Sounds reasonable. I replied to a couple of your responses on the
>> commit
>> >> page, but looks fine overall.
>> >>
>> >> Kanak
>> >> ----------------------------------------
>> >> > Date: Mon, 31 Mar 2014 08:32:58 -0700
>> >> > Subject: Re: Helix Administrator Client and Helix Client strawman
>> >> checked in
>> >> > From: osgigeek@gmail.com
>> >> > To: dev@helix.apache.org
>> >> >
>> >> > I responded to some comments and noted some changes to make. Please
>> >> > see responses inline for questions asked in mail.
>> >> >
>> >> > Keep them coming, this is a good review.
>> >> >
>> >> > Thanks Kanak,
>> >> >
>> >> > Sandeep
>> >> >
>> >> > On Mon, Mar 31, 2014 at 12:01 AM, Kanak Biscuitwala <
>> kanak.b@hotmail.com>
>> >> wrote:
>> >> >>
>> >> >> I added comments directly to
>> >>
>> https://github.com/kanakb/helix/commit/b88217a811f3d175fdc8bd0f0c58467d13de62a3
>> >> >>
>> >> >> General comments:
>> >> >> - What other subclasses of HelixClient are you planning?
>> >> >
>> >> > [Sandeep] None I am only hoping one subclass of administrator at this
>> >> > point. The open question on that one is should we allow users to
>> write
>> >> > their own client extensions?
>> >> >
>> >> >> - It's good to plan out some of these methods, like the CRUD
>> operations
>> >> on spectator, controller, etc, but we shouldn't include these methods
>> in
>> >> the release since we don't plan to implement them right away.
>> >> >> - There are a lot of classes. Do we really need all of them?
>> >> >
>> >> > [Sandeep] Lets get into specific classes and if we dont need them we
>> >> > can discard them, this is an iterative process and not a final cut.
>> >> >
>> >> >> - I don't understand the relationship between HelixConnection and
>> >> HelixClient/HelixAdministratorClient. How will they be related to each
>> >> other?
>> >> > [Sandeep] I had eluded to this in my mail, see 2nd * item. But to
>> >> > elaborate the connection classes will move to SPI and will be held
>> >> > internal to the HelixClient concrete implementations.
>> >> >
>> >> >>
>> >> >> Kanak
>> >> >>
>> >> >> ----------------------------------------
>> >> >>> Date: Sun, 30 Mar 2014 21:33:56 -0700
>> >> >>> Subject: Helix Administrator Client and Helix Client strawman
>> checked
>> >> in
>> >> >>> From: osgigeek@gmail.com
>> >> >>> To: dev@helix.apache.org
>> >> >>>
>> >> >>> Hey guys,
>> >> >>>
>> >> >>> I checked in a strawman for the helix administrator and helix
>> client
>> >> >>> api classes. There are command classes, id classes and model
>> classes
>> >> >>> which tie up the two client apis. The idea is mutation is only
>> allowed
>> >> >>> by Administrator API, the client API is only used for discovery.
>> >> >>>
>> >> >>> Please take a look and let me know of the structure and
>> composition. I
>> >> >>> decided to not go with the composition model as we had discussed
>> i.e.
>> >> >>> HelixCluster having APIs for the creation of entities under it as
>> >> >>> separation between administrator client and regular clients was
>> >> >>> getting clumsy to achieve. So, I decided to switch back to a
>> >> >>> HelixAdministrator and HelixClient based approach which worked
>> better.
>> >> >>>
>> >> >>> Here are the highlights
>> >> >>>
>> >> >>> * The api.role package is no longer needed and all its constituents
>> >> >>> are represented in the model package.
>> >> >>>
>> >> >>> * The existing contents of the api.client package now seem to be
>> >> >>> candidates for spi project (something I plan to start on in
>> parallel
>> >> >>> soon). In other words HelixConnection, HelixConnectionBuilder,
>> >> >>> HelixConnectionFactory, HelixConnectionFactoryListener seem to be
>> >> >>> internal concerns to the implementations of the API.
>> >> >>>
>> >> >>> * If the structure looks good, I will next start on fleshing out
>> the
>> >> >>> contents of each of the command classes. I presume there should be
>> >> >>> existing code I can get information from so I will start there
>> when I
>> >> >>> get a chance. I will need help on the commands, so will ping at the
>> >> >>> appropriate time.
>> >> >>>
>> >> >>> * The contents of api.model package like ZNRecord, ZNRecordDelta
>> etc
>> >> >>> will move under the implementation in core. I will keep
>> >> >>> HelixConfiguration and have configurations derive from it and these
>> >> >>> will eventually get translated before storing into the specific
>> >> >>> implementation.
>> >> >>>
>> >> >>> As usual this is work in progress but wanted to give early
>> visibility
>> >> >>> so feedback, comments are welcome.
>> >> >>>
>> >> >>> Thanks,
>> >> >>>
>> >> >>> Sandeep
>> >> >>
>> >>
>> >>
>>
>
Re: Helix Administrator Client and Helix Client strawman checked in
Posted by kishore g <g....@gmail.com>.
I missed the helixadministratorclient class, cool idea.
On Mar 31, 2014 8:15 PM, "Sandeep Nayak" <os...@gmail.com> wrote:
> Hi Kishore,
>
> Notice that the HelixAdministratorClient extends from the HelixClient,
> so the idea was that only administrators roles are allowed to mutate
> the cluster. A regular HelixClient will only be allowed a view into
> the cluster.If you get an instance of the HelixAdministratorClient you
> do have access to read and write methods but if you get an instance of
> the HelixClient you will only be able to read.
>
> Now it is true that Helix as such does not have roles, but the way I
> envision this working is I see the separation being useful for
> codebases which embed Helix as a cluster management solution to
> provide the access to the right level of cluster management based on
> their access controls. The codebase which embeds Helix may have users
> and roles which will require access to the separate APIs based on the
> access controls for the role the user belongs to thus allowing use of
> Admin or non-Admin capability.
>
> Yes, we can take the LogicalModelExample and rewrite it. Let me get
> all Kanak and your feedback incorporated and checkin another cut
> tonight based on all the feedback and then I want to add the remaining
> pieces to the API before we move to rewriting the sample.
>
> Thanks,
>
> Sandeep
>
> On Mon, Mar 31, 2014 at 3:34 PM, kishore g <g....@gmail.com> wrote:
> > This is looking great. What is the idea behind splitting client (read
> only)
> > and admin (write). I like the separation but not sure what is the
> > motivation. For example, most mutations will involve reading and writing.
> > Do you think it might cause confusion if we have to use client to read
> and
> > admin to write?
> >
> > Will it make sense to take the LogicalModelExample and re-write them
> using
> > these api's.
> >
> > thanks,
> > Kishore G
> >
> >
> > On Mon, Mar 31, 2014 at 3:16 PM, Kanak Biscuitwala <kanak.b@hotmail.com
> >wrote:
> >
> >>
> >> Sounds reasonable. I replied to a couple of your responses on the commit
> >> page, but looks fine overall.
> >>
> >> Kanak
> >> ----------------------------------------
> >> > Date: Mon, 31 Mar 2014 08:32:58 -0700
> >> > Subject: Re: Helix Administrator Client and Helix Client strawman
> >> checked in
> >> > From: osgigeek@gmail.com
> >> > To: dev@helix.apache.org
> >> >
> >> > I responded to some comments and noted some changes to make. Please
> >> > see responses inline for questions asked in mail.
> >> >
> >> > Keep them coming, this is a good review.
> >> >
> >> > Thanks Kanak,
> >> >
> >> > Sandeep
> >> >
> >> > On Mon, Mar 31, 2014 at 12:01 AM, Kanak Biscuitwala <
> kanak.b@hotmail.com>
> >> wrote:
> >> >>
> >> >> I added comments directly to
> >>
> https://github.com/kanakb/helix/commit/b88217a811f3d175fdc8bd0f0c58467d13de62a3
> >> >>
> >> >> General comments:
> >> >> - What other subclasses of HelixClient are you planning?
> >> >
> >> > [Sandeep] None I am only hoping one subclass of administrator at this
> >> > point. The open question on that one is should we allow users to write
> >> > their own client extensions?
> >> >
> >> >> - It's good to plan out some of these methods, like the CRUD
> operations
> >> on spectator, controller, etc, but we shouldn't include these methods in
> >> the release since we don't plan to implement them right away.
> >> >> - There are a lot of classes. Do we really need all of them?
> >> >
> >> > [Sandeep] Lets get into specific classes and if we dont need them we
> >> > can discard them, this is an iterative process and not a final cut.
> >> >
> >> >> - I don't understand the relationship between HelixConnection and
> >> HelixClient/HelixAdministratorClient. How will they be related to each
> >> other?
> >> > [Sandeep] I had eluded to this in my mail, see 2nd * item. But to
> >> > elaborate the connection classes will move to SPI and will be held
> >> > internal to the HelixClient concrete implementations.
> >> >
> >> >>
> >> >> Kanak
> >> >>
> >> >> ----------------------------------------
> >> >>> Date: Sun, 30 Mar 2014 21:33:56 -0700
> >> >>> Subject: Helix Administrator Client and Helix Client strawman
> checked
> >> in
> >> >>> From: osgigeek@gmail.com
> >> >>> To: dev@helix.apache.org
> >> >>>
> >> >>> Hey guys,
> >> >>>
> >> >>> I checked in a strawman for the helix administrator and helix client
> >> >>> api classes. There are command classes, id classes and model classes
> >> >>> which tie up the two client apis. The idea is mutation is only
> allowed
> >> >>> by Administrator API, the client API is only used for discovery.
> >> >>>
> >> >>> Please take a look and let me know of the structure and
> composition. I
> >> >>> decided to not go with the composition model as we had discussed
> i.e.
> >> >>> HelixCluster having APIs for the creation of entities under it as
> >> >>> separation between administrator client and regular clients was
> >> >>> getting clumsy to achieve. So, I decided to switch back to a
> >> >>> HelixAdministrator and HelixClient based approach which worked
> better.
> >> >>>
> >> >>> Here are the highlights
> >> >>>
> >> >>> * The api.role package is no longer needed and all its constituents
> >> >>> are represented in the model package.
> >> >>>
> >> >>> * The existing contents of the api.client package now seem to be
> >> >>> candidates for spi project (something I plan to start on in parallel
> >> >>> soon). In other words HelixConnection, HelixConnectionBuilder,
> >> >>> HelixConnectionFactory, HelixConnectionFactoryListener seem to be
> >> >>> internal concerns to the implementations of the API.
> >> >>>
> >> >>> * If the structure looks good, I will next start on fleshing out the
> >> >>> contents of each of the command classes. I presume there should be
> >> >>> existing code I can get information from so I will start there when
> I
> >> >>> get a chance. I will need help on the commands, so will ping at the
> >> >>> appropriate time.
> >> >>>
> >> >>> * The contents of api.model package like ZNRecord, ZNRecordDelta etc
> >> >>> will move under the implementation in core. I will keep
> >> >>> HelixConfiguration and have configurations derive from it and these
> >> >>> will eventually get translated before storing into the specific
> >> >>> implementation.
> >> >>>
> >> >>> As usual this is work in progress but wanted to give early
> visibility
> >> >>> so feedback, comments are welcome.
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> Sandeep
> >> >>
> >>
> >>
>
Re: Helix Administrator Client and Helix Client strawman checked in
Posted by Sandeep Nayak <os...@gmail.com>.
Hi Kishore,
Notice that the HelixAdministratorClient extends from the HelixClient,
so the idea was that only administrators roles are allowed to mutate
the cluster. A regular HelixClient will only be allowed a view into
the cluster.If you get an instance of the HelixAdministratorClient you
do have access to read and write methods but if you get an instance of
the HelixClient you will only be able to read.
Now it is true that Helix as such does not have roles, but the way I
envision this working is I see the separation being useful for
codebases which embed Helix as a cluster management solution to
provide the access to the right level of cluster management based on
their access controls. The codebase which embeds Helix may have users
and roles which will require access to the separate APIs based on the
access controls for the role the user belongs to thus allowing use of
Admin or non-Admin capability.
Yes, we can take the LogicalModelExample and rewrite it. Let me get
all Kanak and your feedback incorporated and checkin another cut
tonight based on all the feedback and then I want to add the remaining
pieces to the API before we move to rewriting the sample.
Thanks,
Sandeep
On Mon, Mar 31, 2014 at 3:34 PM, kishore g <g....@gmail.com> wrote:
> This is looking great. What is the idea behind splitting client (read only)
> and admin (write). I like the separation but not sure what is the
> motivation. For example, most mutations will involve reading and writing.
> Do you think it might cause confusion if we have to use client to read and
> admin to write?
>
> Will it make sense to take the LogicalModelExample and re-write them using
> these api's.
>
> thanks,
> Kishore G
>
>
> On Mon, Mar 31, 2014 at 3:16 PM, Kanak Biscuitwala <ka...@hotmail.com>wrote:
>
>>
>> Sounds reasonable. I replied to a couple of your responses on the commit
>> page, but looks fine overall.
>>
>> Kanak
>> ----------------------------------------
>> > Date: Mon, 31 Mar 2014 08:32:58 -0700
>> > Subject: Re: Helix Administrator Client and Helix Client strawman
>> checked in
>> > From: osgigeek@gmail.com
>> > To: dev@helix.apache.org
>> >
>> > I responded to some comments and noted some changes to make. Please
>> > see responses inline for questions asked in mail.
>> >
>> > Keep them coming, this is a good review.
>> >
>> > Thanks Kanak,
>> >
>> > Sandeep
>> >
>> > On Mon, Mar 31, 2014 at 12:01 AM, Kanak Biscuitwala <ka...@hotmail.com>
>> wrote:
>> >>
>> >> I added comments directly to
>> https://github.com/kanakb/helix/commit/b88217a811f3d175fdc8bd0f0c58467d13de62a3
>> >>
>> >> General comments:
>> >> - What other subclasses of HelixClient are you planning?
>> >
>> > [Sandeep] None I am only hoping one subclass of administrator at this
>> > point. The open question on that one is should we allow users to write
>> > their own client extensions?
>> >
>> >> - It's good to plan out some of these methods, like the CRUD operations
>> on spectator, controller, etc, but we shouldn't include these methods in
>> the release since we don't plan to implement them right away.
>> >> - There are a lot of classes. Do we really need all of them?
>> >
>> > [Sandeep] Lets get into specific classes and if we dont need them we
>> > can discard them, this is an iterative process and not a final cut.
>> >
>> >> - I don't understand the relationship between HelixConnection and
>> HelixClient/HelixAdministratorClient. How will they be related to each
>> other?
>> > [Sandeep] I had eluded to this in my mail, see 2nd * item. But to
>> > elaborate the connection classes will move to SPI and will be held
>> > internal to the HelixClient concrete implementations.
>> >
>> >>
>> >> Kanak
>> >>
>> >> ----------------------------------------
>> >>> Date: Sun, 30 Mar 2014 21:33:56 -0700
>> >>> Subject: Helix Administrator Client and Helix Client strawman checked
>> in
>> >>> From: osgigeek@gmail.com
>> >>> To: dev@helix.apache.org
>> >>>
>> >>> Hey guys,
>> >>>
>> >>> I checked in a strawman for the helix administrator and helix client
>> >>> api classes. There are command classes, id classes and model classes
>> >>> which tie up the two client apis. The idea is mutation is only allowed
>> >>> by Administrator API, the client API is only used for discovery.
>> >>>
>> >>> Please take a look and let me know of the structure and composition. I
>> >>> decided to not go with the composition model as we had discussed i.e.
>> >>> HelixCluster having APIs for the creation of entities under it as
>> >>> separation between administrator client and regular clients was
>> >>> getting clumsy to achieve. So, I decided to switch back to a
>> >>> HelixAdministrator and HelixClient based approach which worked better.
>> >>>
>> >>> Here are the highlights
>> >>>
>> >>> * The api.role package is no longer needed and all its constituents
>> >>> are represented in the model package.
>> >>>
>> >>> * The existing contents of the api.client package now seem to be
>> >>> candidates for spi project (something I plan to start on in parallel
>> >>> soon). In other words HelixConnection, HelixConnectionBuilder,
>> >>> HelixConnectionFactory, HelixConnectionFactoryListener seem to be
>> >>> internal concerns to the implementations of the API.
>> >>>
>> >>> * If the structure looks good, I will next start on fleshing out the
>> >>> contents of each of the command classes. I presume there should be
>> >>> existing code I can get information from so I will start there when I
>> >>> get a chance. I will need help on the commands, so will ping at the
>> >>> appropriate time.
>> >>>
>> >>> * The contents of api.model package like ZNRecord, ZNRecordDelta etc
>> >>> will move under the implementation in core. I will keep
>> >>> HelixConfiguration and have configurations derive from it and these
>> >>> will eventually get translated before storing into the specific
>> >>> implementation.
>> >>>
>> >>> As usual this is work in progress but wanted to give early visibility
>> >>> so feedback, comments are welcome.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Sandeep
>> >>
>>
>>
Re: Helix Administrator Client and Helix Client strawman checked in
Posted by kishore g <g....@gmail.com>.
This is looking great. What is the idea behind splitting client (read only)
and admin (write). I like the separation but not sure what is the
motivation. For example, most mutations will involve reading and writing.
Do you think it might cause confusion if we have to use client to read and
admin to write?
Will it make sense to take the LogicalModelExample and re-write them using
these api's.
thanks,
Kishore G
On Mon, Mar 31, 2014 at 3:16 PM, Kanak Biscuitwala <ka...@hotmail.com>wrote:
>
> Sounds reasonable. I replied to a couple of your responses on the commit
> page, but looks fine overall.
>
> Kanak
> ----------------------------------------
> > Date: Mon, 31 Mar 2014 08:32:58 -0700
> > Subject: Re: Helix Administrator Client and Helix Client strawman
> checked in
> > From: osgigeek@gmail.com
> > To: dev@helix.apache.org
> >
> > I responded to some comments and noted some changes to make. Please
> > see responses inline for questions asked in mail.
> >
> > Keep them coming, this is a good review.
> >
> > Thanks Kanak,
> >
> > Sandeep
> >
> > On Mon, Mar 31, 2014 at 12:01 AM, Kanak Biscuitwala <ka...@hotmail.com>
> wrote:
> >>
> >> I added comments directly to
> https://github.com/kanakb/helix/commit/b88217a811f3d175fdc8bd0f0c58467d13de62a3
> >>
> >> General comments:
> >> - What other subclasses of HelixClient are you planning?
> >
> > [Sandeep] None I am only hoping one subclass of administrator at this
> > point. The open question on that one is should we allow users to write
> > their own client extensions?
> >
> >> - It's good to plan out some of these methods, like the CRUD operations
> on spectator, controller, etc, but we shouldn't include these methods in
> the release since we don't plan to implement them right away.
> >> - There are a lot of classes. Do we really need all of them?
> >
> > [Sandeep] Lets get into specific classes and if we dont need them we
> > can discard them, this is an iterative process and not a final cut.
> >
> >> - I don't understand the relationship between HelixConnection and
> HelixClient/HelixAdministratorClient. How will they be related to each
> other?
> > [Sandeep] I had eluded to this in my mail, see 2nd * item. But to
> > elaborate the connection classes will move to SPI and will be held
> > internal to the HelixClient concrete implementations.
> >
> >>
> >> Kanak
> >>
> >> ----------------------------------------
> >>> Date: Sun, 30 Mar 2014 21:33:56 -0700
> >>> Subject: Helix Administrator Client and Helix Client strawman checked
> in
> >>> From: osgigeek@gmail.com
> >>> To: dev@helix.apache.org
> >>>
> >>> Hey guys,
> >>>
> >>> I checked in a strawman for the helix administrator and helix client
> >>> api classes. There are command classes, id classes and model classes
> >>> which tie up the two client apis. The idea is mutation is only allowed
> >>> by Administrator API, the client API is only used for discovery.
> >>>
> >>> Please take a look and let me know of the structure and composition. I
> >>> decided to not go with the composition model as we had discussed i.e.
> >>> HelixCluster having APIs for the creation of entities under it as
> >>> separation between administrator client and regular clients was
> >>> getting clumsy to achieve. So, I decided to switch back to a
> >>> HelixAdministrator and HelixClient based approach which worked better.
> >>>
> >>> Here are the highlights
> >>>
> >>> * The api.role package is no longer needed and all its constituents
> >>> are represented in the model package.
> >>>
> >>> * The existing contents of the api.client package now seem to be
> >>> candidates for spi project (something I plan to start on in parallel
> >>> soon). In other words HelixConnection, HelixConnectionBuilder,
> >>> HelixConnectionFactory, HelixConnectionFactoryListener seem to be
> >>> internal concerns to the implementations of the API.
> >>>
> >>> * If the structure looks good, I will next start on fleshing out the
> >>> contents of each of the command classes. I presume there should be
> >>> existing code I can get information from so I will start there when I
> >>> get a chance. I will need help on the commands, so will ping at the
> >>> appropriate time.
> >>>
> >>> * The contents of api.model package like ZNRecord, ZNRecordDelta etc
> >>> will move under the implementation in core. I will keep
> >>> HelixConfiguration and have configurations derive from it and these
> >>> will eventually get translated before storing into the specific
> >>> implementation.
> >>>
> >>> As usual this is work in progress but wanted to give early visibility
> >>> so feedback, comments are welcome.
> >>>
> >>> Thanks,
> >>>
> >>> Sandeep
> >>
>
>
RE: Helix Administrator Client and Helix Client strawman checked in
Posted by Kanak Biscuitwala <ka...@hotmail.com>.
Sounds reasonable. I replied to a couple of your responses on the commit page, but looks fine overall.
Kanak
----------------------------------------
> Date: Mon, 31 Mar 2014 08:32:58 -0700
> Subject: Re: Helix Administrator Client and Helix Client strawman checked in
> From: osgigeek@gmail.com
> To: dev@helix.apache.org
>
> I responded to some comments and noted some changes to make. Please
> see responses inline for questions asked in mail.
>
> Keep them coming, this is a good review.
>
> Thanks Kanak,
>
> Sandeep
>
> On Mon, Mar 31, 2014 at 12:01 AM, Kanak Biscuitwala <ka...@hotmail.com> wrote:
>>
>> I added comments directly to https://github.com/kanakb/helix/commit/b88217a811f3d175fdc8bd0f0c58467d13de62a3
>>
>> General comments:
>> - What other subclasses of HelixClient are you planning?
>
> [Sandeep] None I am only hoping one subclass of administrator at this
> point. The open question on that one is should we allow users to write
> their own client extensions?
>
>> - It's good to plan out some of these methods, like the CRUD operations on spectator, controller, etc, but we shouldn't include these methods in the release since we don't plan to implement them right away.
>> - There are a lot of classes. Do we really need all of them?
>
> [Sandeep] Lets get into specific classes and if we dont need them we
> can discard them, this is an iterative process and not a final cut.
>
>> - I don't understand the relationship between HelixConnection and HelixClient/HelixAdministratorClient. How will they be related to each other?
> [Sandeep] I had eluded to this in my mail, see 2nd * item. But to
> elaborate the connection classes will move to SPI and will be held
> internal to the HelixClient concrete implementations.
>
>>
>> Kanak
>>
>> ----------------------------------------
>>> Date: Sun, 30 Mar 2014 21:33:56 -0700
>>> Subject: Helix Administrator Client and Helix Client strawman checked in
>>> From: osgigeek@gmail.com
>>> To: dev@helix.apache.org
>>>
>>> Hey guys,
>>>
>>> I checked in a strawman for the helix administrator and helix client
>>> api classes. There are command classes, id classes and model classes
>>> which tie up the two client apis. The idea is mutation is only allowed
>>> by Administrator API, the client API is only used for discovery.
>>>
>>> Please take a look and let me know of the structure and composition. I
>>> decided to not go with the composition model as we had discussed i.e.
>>> HelixCluster having APIs for the creation of entities under it as
>>> separation between administrator client and regular clients was
>>> getting clumsy to achieve. So, I decided to switch back to a
>>> HelixAdministrator and HelixClient based approach which worked better.
>>>
>>> Here are the highlights
>>>
>>> * The api.role package is no longer needed and all its constituents
>>> are represented in the model package.
>>>
>>> * The existing contents of the api.client package now seem to be
>>> candidates for spi project (something I plan to start on in parallel
>>> soon). In other words HelixConnection, HelixConnectionBuilder,
>>> HelixConnectionFactory, HelixConnectionFactoryListener seem to be
>>> internal concerns to the implementations of the API.
>>>
>>> * If the structure looks good, I will next start on fleshing out the
>>> contents of each of the command classes. I presume there should be
>>> existing code I can get information from so I will start there when I
>>> get a chance. I will need help on the commands, so will ping at the
>>> appropriate time.
>>>
>>> * The contents of api.model package like ZNRecord, ZNRecordDelta etc
>>> will move under the implementation in core. I will keep
>>> HelixConfiguration and have configurations derive from it and these
>>> will eventually get translated before storing into the specific
>>> implementation.
>>>
>>> As usual this is work in progress but wanted to give early visibility
>>> so feedback, comments are welcome.
>>>
>>> Thanks,
>>>
>>> Sandeep
>>
Re: Helix Administrator Client and Helix Client strawman checked in
Posted by Sandeep Nayak <os...@gmail.com>.
I responded to some comments and noted some changes to make. Please
see responses inline for questions asked in mail.
Keep them coming, this is a good review.
Thanks Kanak,
Sandeep
On Mon, Mar 31, 2014 at 12:01 AM, Kanak Biscuitwala <ka...@hotmail.com> wrote:
>
> I added comments directly to https://github.com/kanakb/helix/commit/b88217a811f3d175fdc8bd0f0c58467d13de62a3
>
> General comments:
> - What other subclasses of HelixClient are you planning?
[Sandeep] None I am only hoping one subclass of administrator at this
point. The open question on that one is should we allow users to write
their own client extensions?
> - It's good to plan out some of these methods, like the CRUD operations on spectator, controller, etc, but we shouldn't include these methods in the release since we don't plan to implement them right away.
> - There are a lot of classes. Do we really need all of them?
[Sandeep] Lets get into specific classes and if we dont need them we
can discard them, this is an iterative process and not a final cut.
> - I don't understand the relationship between HelixConnection and HelixClient/HelixAdministratorClient. How will they be related to each other?
[Sandeep] I had eluded to this in my mail, see 2nd * item. But to
elaborate the connection classes will move to SPI and will be held
internal to the HelixClient concrete implementations.
>
> Kanak
>
> ----------------------------------------
>> Date: Sun, 30 Mar 2014 21:33:56 -0700
>> Subject: Helix Administrator Client and Helix Client strawman checked in
>> From: osgigeek@gmail.com
>> To: dev@helix.apache.org
>>
>> Hey guys,
>>
>> I checked in a strawman for the helix administrator and helix client
>> api classes. There are command classes, id classes and model classes
>> which tie up the two client apis. The idea is mutation is only allowed
>> by Administrator API, the client API is only used for discovery.
>>
>> Please take a look and let me know of the structure and composition. I
>> decided to not go with the composition model as we had discussed i.e.
>> HelixCluster having APIs for the creation of entities under it as
>> separation between administrator client and regular clients was
>> getting clumsy to achieve. So, I decided to switch back to a
>> HelixAdministrator and HelixClient based approach which worked better.
>>
>> Here are the highlights
>>
>> * The api.role package is no longer needed and all its constituents
>> are represented in the model package.
>>
>> * The existing contents of the api.client package now seem to be
>> candidates for spi project (something I plan to start on in parallel
>> soon). In other words HelixConnection, HelixConnectionBuilder,
>> HelixConnectionFactory, HelixConnectionFactoryListener seem to be
>> internal concerns to the implementations of the API.
>>
>> * If the structure looks good, I will next start on fleshing out the
>> contents of each of the command classes. I presume there should be
>> existing code I can get information from so I will start there when I
>> get a chance. I will need help on the commands, so will ping at the
>> appropriate time.
>>
>> * The contents of api.model package like ZNRecord, ZNRecordDelta etc
>> will move under the implementation in core. I will keep
>> HelixConfiguration and have configurations derive from it and these
>> will eventually get translated before storing into the specific
>> implementation.
>>
>> As usual this is work in progress but wanted to give early visibility
>> so feedback, comments are welcome.
>>
>> Thanks,
>>
>> Sandeep
>
RE: Helix Administrator Client and Helix Client strawman checked in
Posted by Kanak Biscuitwala <ka...@hotmail.com>.
I added comments directly to https://github.com/kanakb/helix/commit/b88217a811f3d175fdc8bd0f0c58467d13de62a3
General comments:
- What other subclasses of HelixClient are you planning?
- It's good to plan out some of these methods, like the CRUD operations on spectator, controller, etc, but we shouldn't include these methods in the release since we don't plan to implement them right away.
- There are a lot of classes. Do we really need all of them?
- I don't understand the relationship between HelixConnection and HelixClient/HelixAdministratorClient. How will they be related to each other?
Kanak
----------------------------------------
> Date: Sun, 30 Mar 2014 21:33:56 -0700
> Subject: Helix Administrator Client and Helix Client strawman checked in
> From: osgigeek@gmail.com
> To: dev@helix.apache.org
>
> Hey guys,
>
> I checked in a strawman for the helix administrator and helix client
> api classes. There are command classes, id classes and model classes
> which tie up the two client apis. The idea is mutation is only allowed
> by Administrator API, the client API is only used for discovery.
>
> Please take a look and let me know of the structure and composition. I
> decided to not go with the composition model as we had discussed i.e.
> HelixCluster having APIs for the creation of entities under it as
> separation between administrator client and regular clients was
> getting clumsy to achieve. So, I decided to switch back to a
> HelixAdministrator and HelixClient based approach which worked better.
>
> Here are the highlights
>
> * The api.role package is no longer needed and all its constituents
> are represented in the model package.
>
> * The existing contents of the api.client package now seem to be
> candidates for spi project (something I plan to start on in parallel
> soon). In other words HelixConnection, HelixConnectionBuilder,
> HelixConnectionFactory, HelixConnectionFactoryListener seem to be
> internal concerns to the implementations of the API.
>
> * If the structure looks good, I will next start on fleshing out the
> contents of each of the command classes. I presume there should be
> existing code I can get information from so I will start there when I
> get a chance. I will need help on the commands, so will ping at the
> appropriate time.
>
> * The contents of api.model package like ZNRecord, ZNRecordDelta etc
> will move under the implementation in core. I will keep
> HelixConfiguration and have configurations derive from it and these
> will eventually get translated before storing into the specific
> implementation.
>
> As usual this is work in progress but wanted to give early visibility
> so feedback, comments are welcome.
>
> Thanks,
>
> Sandeep