Ignoring a node as a Service Grid deployment candidate

[Denis Magda]

Igniters,

Presently every node that is a part of a cluster listens for Service
Grid assignment changes in order to find out whether a service has to be
deployed on it or not.

However, there is a possible case when a node is not considered to be a
target for service A at all during its lifetime. But the node has to
have a class definition of service A in its classpath in any case just
to check whether it's a target one or not.
In big cluster with many unrelated clients this can be an annoying thing
to take care of.

My understanding is that it makes sense to implement "all or nothing"
like approach for Service Grid cause it's the most easiest and
straightforward.
If a service is considered to be deployed on node A at some point of
time then node A has to have  class definitions of all the services in
its classpath.
On the other hand if node B is not considered to be a deployment target
for any service then it will be excluded from services deployment
related logic. We can add a special parameter to IgniteConfiguration to
address this.

What do you think on this approach? If we want to support more flexible
configurations lets go ahead and discuss them here.

--
Denis

[Roman Shtykh]

Denis,

What will happen if node B becomes a deployment target due to topology changes?

Thanks,
Roman



On Sunday, December 6, 2015 5:17 PM, Denis Magda <[hidden email]> wrote:
Igniters,

Presently every node that is a part of a cluster listens for Service
Grid assignment changes in order to find out whether a service has to be
deployed on it or not.

However, there is a possible case when a node is not considered to be a
target for service A at all during its lifetime. But the node has to
have a class definition of service A in its classpath in any case just
to check whether it's a target one or not.
In big cluster with many unrelated clients this can be an annoying thing
to take care of.

My understanding is that it makes sense to implement "all or nothing"
like approach for Service Grid cause it's the most easiest and
straightforward.
If a service is considered to be deployed on node A at some point of
time then node A has to have  class definitions of all the services in
its classpath.
On the other hand if node B is not considered to be a deployment target
for any service then it will be excluded from services deployment
related logic. We can add a special parameter to IgniteConfiguration to
address this.

What do you think on this approach? If we want to support more flexible
configurations lets go ahead and discuss them here.

--
Denis

[dsetrakyan]

I don’t think that using Class definition to check if the node is part of
service grid deployment is wrong. We should use the String class name
instead. If we take this approach, will this fix the current class
deployment which requires class definition on all the nodes?

On Sun, Dec 6, 2015 at 6:26 PM, Roman Shtykh <[hidden email]>
wrote:

> Denis,
>
> What will happen if node B becomes a deployment target due to topology
> changes?
>
> Thanks,
> Roman
>
>
>
> On Sunday, December 6, 2015 5:17 PM, Denis Magda <[hidden email]>
> wrote:
> Igniters,
>
> Presently every node that is a part of a cluster listens for Service
> Grid assignment changes in order to find out whether a service has to be
> deployed on it or not.
>
> However, there is a possible case when a node is not considered to be a
> target for service A at all during its lifetime. But the node has to
> have a class definition of service A in its classpath in any case just
> to check whether it's a target one or not.
> In big cluster with many unrelated clients this can be an annoying thing
> to take care of.
>
> My understanding is that it makes sense to implement "all or nothing"
> like approach for Service Grid cause it's the most easiest and
> straightforward.
> If a service is considered to be deployed on node A at some point of
> time then node A has to have  class definitions of all the services in
> its classpath.
> On the other hand if node B is not considered to be a deployment target
> for any service then it will be excluded from services deployment
> related logic. We can add a special parameter to IgniteConfiguration to
> address this.
>
> What do you think on this approach? If we want to support more flexible
> configurations lets go ahead and discuss them here.
>
> --
> Denis
>

[Denis Magda]

Dmitriy,

Agree that your solution sounds better. Created a ticket
https://issues.apache.org/jira/browse/IGNITE-2091

Is there anyone in the community who can pick it up and fix the issue
during the nearest month?

--
Denis

On 12/7/2015 8:08 AM, Dmitriy Setrakyan wrote:

> I don’t think that using Class definition to check if the node is part of
> service grid deployment is wrong. We should use the String class name
> instead. If we take this approach, will this fix the current class
> deployment which requires class definition on all the nodes?
>
> On Sun, Dec 6, 2015 at 6:26 PM, Roman Shtykh <[hidden email]>
> wrote:
>
>> Denis,
>>
>> What will happen if node B becomes a deployment target due to topology
>> changes?
>>
>> Thanks,
>> Roman
>>
>>
>>
>> On Sunday, December 6, 2015 5:17 PM, Denis Magda <[hidden email]>
>> wrote:
>> Igniters,
>>
>> Presently every node that is a part of a cluster listens for Service
>> Grid assignment changes in order to find out whether a service has to be
>> deployed on it or not.
>>
>> However, there is a possible case when a node is not considered to be a
>> target for service A at all during its lifetime. But the node has to
>> have a class definition of service A in its classpath in any case just
>> to check whether it's a target one or not.
>> In big cluster with many unrelated clients this can be an annoying thing
>> to take care of.
>>
>> My understanding is that it makes sense to implement "all or nothing"
>> like approach for Service Grid cause it's the most easiest and
>> straightforward.
>> If a service is considered to be deployed on node A at some point of
>> time then node A has to have  class definitions of all the services in
>> its classpath.
>> On the other hand if node B is not considered to be a deployment target
>> for any service then it will be excluded from services deployment
>> related logic. We can add a special parameter to IgniteConfiguration to
>> address this.
>>
>> What do you think on this approach? If we want to support more flexible
>> configurations lets go ahead and discuss them here.
>>
>> --
>> Denis
>>