Service grid redesign

[dsetrakyan]

On Tue, Jul 24, 2018 at 9:14 PM, Vyacheslav Daradur <[hidden email]>
wrote:

> Igniters, please help me to clarify the following questions:
>
> 1). According to the issue [1] we should propagate services deployment
> results to an initiator, that means we should wait for wor
> Service#init method completion.
> How should we handle Service#init method hangup?
> I propose to introduce some kind of
> IgniteSystemProperties#IGNITE_SERVICE_INIT_TIMEOUT to interrupt long
> initialization.
>

I think such timeout should be determined on per-service level. Can we make
it part of the service configuration, or pass it into deploy method?


> 2) Should we automatically undeploy services, which had been deployed
> using #deployKeyAffinitySingleton, on destroying of related IgniteCache?
>
>
This is a great question. Will the service be able to continue operating
after the cache is destroyed? If not, I would undeploy it automatically. If
yes, I would keep it. Please make sure that you are carefully printing out
informative logs in either case, to make sure that there is no magic
happening that is hidden from users.

> Thoughts?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-3392
> On Tue, Jul 24, 2018 at 3:01 PM Vyacheslav Daradur <[hidden email]>
> wrote:
> >
> > Got it.
> >
> > Yes, we will preserve this behavior.
> >
> > Thanks!
> > On Tue, Jul 24, 2018 at 2:20 PM Dmitriy Setrakyan <[hidden email]>
> wrote:
> > >
> > > By default the client nodes should be excluded form service
> deployment. The
> > > only way to include clients is to explicitly specify them through node
> > > filter. This is how services are deployed today and we should preserve
> this
> > > behavior.
> > >
> > > D.
> > >
> > > On Tue, Jul 24, 2018 at 11:20 AM, Denis Mekhanikov <
> [hidden email]>
> > > wrote:
> > >
> > > > Maybe let's keep the functionality the way it is, since it doesn't
> > > > interfere with the IEP?
> > > >
> > > > But I think, it's worth mentioning as a warning in log, that a
> service is
> > > > deployed on a client node.
> > > >
> > > > Denis
> > > >
> > > > вт, 24 июл. 2018 г. в 12:44, Vyacheslav Daradur <[hidden email]
> >:
> > > >
> > > > > No, it's doesn't complicate implementation on the current stage.
> > > > >
> > > > > But we will have to change assignment function to forbid client
> nodes
> > > > > even if configuration's node filter resolves them it can be not
> > > > > transparent for the end user.
> > > > >
> > > > > I think the only use case to have such behavior is: hosting of not
> > > > > collocated services on data free nodes with access to IgniteCaches
> on
> > > > > remote nodes in the same cluster.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Jul 24, 2018 at 12:10 PM Denis Mekhanikov <
> [hidden email]
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > I don't think, that client nodes, that host services make much
> sense.
> > > > > > May we forbid it? Does anybody know, when it may be useful?
> > > > > >
> > > > > > Vyacheslav, does it complicate the implementation somehow?
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > вт, 24 июл. 2018 г. в 11:57, Vyacheslav Daradur <
> [hidden email]>:
> > > > > >
> > > > > > > Hi, Igniters!
> > > > > > >
> > > > > > > I am close to completing the main tasks and I'm going to
> request a
> > > > > > > review in a couple weeks.
> > > > > > >
> > > > > > > I have a question about the new design:
> > > > > > >
> > > > > > > The current implementation of Service Grid doesn't' take into
> account
> > > > > > > Ignition#client(true).
> > > > > > > It means that *clients* nodes are able to host services. There
> are
> > > > > > > some tests that expect such behavior.
> > > > > > >
> > > > > > > Services assignments are managed by a predicate only
> > > > > > > (ServiceConfiguration#setNodeFilter(IgnitePredicate<
> ClusterNode>).
> > > > > > >
> > > > > > > Should deployment on clients nodes be forbidden or we
> shouldn't mix
> > > > > > > concepts for IgniteCache with Service Grid?
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Jun 20, 2018 at 1:46 AM Dmitriy Setrakyan <
> > > > > [hidden email]>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Tue, Jun 19, 2018 at 1:50 PM, Vyacheslav Daradur <
> > > > > [hidden email]
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Dmitriy,
> > > > > > > > >
> > > > > > > > > Yes, the task [1] is planned to be implemented once the
> main
> > > > tasks
> > > > > > > > > will be completed.
> > > > > > > > >
> > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-8367
> > > > > > > >
> > > > > > > >
> > > > > > > > Awesome! This is a huge addition to the project.
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Jun 19, 2018 at 10:06 PM Dmitriy Setrakyan
> > > > > > > > > <[hidden email]> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Vyacheslav,
> > > > > > > > > >
> > > > > > > > > > How about service redeployment in case if user wants to
> update
> > > > > the
> > > > > > > code?
> > > > > > > > > Is
> > > > > > > > > > this planned?
> > > > > > > > > >
> > > > > > > > > > D.
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
>
>
>
> --
> Best Regards, Vyacheslav D.
>

[daradurvs]

> I think such timeout should be determined on per-service level. Can we make
> it part of the service configuration, or pass it into deploy method?

Agree, per ServiceConfiguration level is more flexible solution.

> This is a great question. Will the service be able to continue operating
> after the cache is destroyed? If not, I would undeploy it automatically. If
> yes, I would keep it. Please make sure that you are carefully printing out
> informative logs in either case, to make sure that there is no magic
> happening that is hidden from users.

A service will be able to work till topology's change after that we
have to recalculate assignments and at this moment we won't determine
suitable nodes.

I will fill new tickets to work on these questions and to implement
solutions in the second iteration if nobody doesn't mind.
Anyway, it will have been done to a release.
On Wed, Jul 25, 2018 at 12:08 PM Dmitriy Setrakyan
<[hidden email]> wrote:

>
> On Tue, Jul 24, 2018 at 9:14 PM, Vyacheslav Daradur <[hidden email]>
> wrote:
>
> > Igniters, please help me to clarify the following questions:
> >
> > 1). According to the issue [1] we should propagate services deployment
> > results to an initiator, that means we should wait for wor
> > Service#init method completion.
> > How should we handle Service#init method hangup?
> > I propose to introduce some kind of
> > IgniteSystemProperties#IGNITE_SERVICE_INIT_TIMEOUT to interrupt long
> > initialization.
> >
>
> I think such timeout should be determined on per-service level. Can we make
> it part of the service configuration, or pass it into deploy method?
>
>
> > 2) Should we automatically undeploy services, which had been deployed
> > using #deployKeyAffinitySingleton, on destroying of related IgniteCache?
> >
> >
> This is a great question. Will the service be able to continue operating
> after the cache is destroyed? If not, I would undeploy it automatically. If
> yes, I would keep it. Please make sure that you are carefully printing out
> informative logs in either case, to make sure that there is no magic
> happening that is hidden from users.
>
>
> > Thoughts?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-3392
> > On Tue, Jul 24, 2018 at 3:01 PM Vyacheslav Daradur <[hidden email]>
> > wrote:
> > >
> > > Got it.
> > >
> > > Yes, we will preserve this behavior.
> > >
> > > Thanks!
> > > On Tue, Jul 24, 2018 at 2:20 PM Dmitriy Setrakyan <[hidden email]>
> > wrote:
> > > >
> > > > By default the client nodes should be excluded form service
> > deployment. The
> > > > only way to include clients is to explicitly specify them through node
> > > > filter. This is how services are deployed today and we should preserve
> > this
> > > > behavior.
> > > >
> > > > D.
> > > >
> > > > On Tue, Jul 24, 2018 at 11:20 AM, Denis Mekhanikov <
> > [hidden email]>
> > > > wrote:
> > > >
> > > > > Maybe let's keep the functionality the way it is, since it doesn't
> > > > > interfere with the IEP?
> > > > >
> > > > > But I think, it's worth mentioning as a warning in log, that a
> > service is
> > > > > deployed on a client node.
> > > > >
> > > > > Denis
> > > > >
> > > > > вт, 24 июл. 2018 г. в 12:44, Vyacheslav Daradur <[hidden email]
> > >:
> > > > >
> > > > > > No, it's doesn't complicate implementation on the current stage.
> > > > > >
> > > > > > But we will have to change assignment function to forbid client
> > nodes
> > > > > > even if configuration's node filter resolves them it can be not
> > > > > > transparent for the end user.
> > > > > >
> > > > > > I think the only use case to have such behavior is: hosting of not
> > > > > > collocated services on data free nodes with access to IgniteCaches
> > on
> > > > > > remote nodes in the same cluster.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Jul 24, 2018 at 12:10 PM Denis Mekhanikov <
> > [hidden email]
> > > > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > I don't think, that client nodes, that host services make much
> > sense.
> > > > > > > May we forbid it? Does anybody know, when it may be useful?
> > > > > > >
> > > > > > > Vyacheslav, does it complicate the implementation somehow?
> > > > > > >
> > > > > > > Denis
> > > > > > >
> > > > > > > вт, 24 июл. 2018 г. в 11:57, Vyacheslav Daradur <
> > [hidden email]>:
> > > > > > >
> > > > > > > > Hi, Igniters!
> > > > > > > >
> > > > > > > > I am close to completing the main tasks and I'm going to
> > request a
> > > > > > > > review in a couple weeks.
> > > > > > > >
> > > > > > > > I have a question about the new design:
> > > > > > > >
> > > > > > > > The current implementation of Service Grid doesn't' take into
> > account
> > > > > > > > Ignition#client(true).
> > > > > > > > It means that *clients* nodes are able to host services. There
> > are
> > > > > > > > some tests that expect such behavior.
> > > > > > > >
> > > > > > > > Services assignments are managed by a predicate only
> > > > > > > > (ServiceConfiguration#setNodeFilter(IgnitePredicate<
> > ClusterNode>).
> > > > > > > >
> > > > > > > > Should deployment on clients nodes be forbidden or we
> > shouldn't mix
> > > > > > > > concepts for IgniteCache with Service Grid?
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Jun 20, 2018 at 1:46 AM Dmitriy Setrakyan <
> > > > > > [hidden email]>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Jun 19, 2018 at 1:50 PM, Vyacheslav Daradur <
> > > > > > [hidden email]
> > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi Dmitriy,
> > > > > > > > > >
> > > > > > > > > > Yes, the task [1] is planned to be implemented once the
> > main
> > > > > tasks
> > > > > > > > > > will be completed.
> > > > > > > > > >
> > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-8367
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Awesome! This is a huge addition to the project.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, Jun 19, 2018 at 10:06 PM Dmitriy Setrakyan
> > > > > > > > > > <[hidden email]> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Vyacheslav,
> > > > > > > > > > >
> > > > > > > > > > > How about service redeployment in case if user wants to
> > update
> > > > > > the
> > > > > > > > code?
> > > > > > > > > > Is
> > > > > > > > > > > this planned?
> > > > > > > > > > >
> > > > > > > > > > > D.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >

--
Best Regards, Vyacheslav D.

[daradurvs]

FYI, I've filled the tickets:
https://issues.apache.org/jira/browse/IGNITE-9075
https://issues.apache.org/jira/browse/IGNITE-9076
On Wed, Jul 25, 2018 at 12:54 PM Vyacheslav Daradur <[hidden email]> wrote:

>
> > I think such timeout should be determined on per-service level. Can we make
> > it part of the service configuration, or pass it into deploy method?
>
> Agree, per ServiceConfiguration level is more flexible solution.
>
> > This is a great question. Will the service be able to continue operating
> > after the cache is destroyed? If not, I would undeploy it automatically. If
> > yes, I would keep it. Please make sure that you are carefully printing out
> > informative logs in either case, to make sure that there is no magic
> > happening that is hidden from users.
>
> A service will be able to work till topology's change after that we
> have to recalculate assignments and at this moment we won't determine
> suitable nodes.
>
> I will fill new tickets to work on these questions and to implement
> solutions in the second iteration if nobody doesn't mind.
> Anyway, it will have been done to a release.
> On Wed, Jul 25, 2018 at 12:08 PM Dmitriy Setrakyan
> <[hidden email]> wrote:
> >
> > On Tue, Jul 24, 2018 at 9:14 PM, Vyacheslav Daradur <[hidden email]>
> > wrote:
> >
> > > Igniters, please help me to clarify the following questions:
> > >
> > > 1). According to the issue [1] we should propagate services deployment
> > > results to an initiator, that means we should wait for wor
> > > Service#init method completion.
> > > How should we handle Service#init method hangup?
> > > I propose to introduce some kind of
> > > IgniteSystemProperties#IGNITE_SERVICE_INIT_TIMEOUT to interrupt long
> > > initialization.
> > >
> >
> > I think such timeout should be determined on per-service level. Can we make
> > it part of the service configuration, or pass it into deploy method?
> >
> >
> > > 2) Should we automatically undeploy services, which had been deployed
> > > using #deployKeyAffinitySingleton, on destroying of related IgniteCache?
> > >
> > >
> > This is a great question. Will the service be able to continue operating
> > after the cache is destroyed? If not, I would undeploy it automatically. If
> > yes, I would keep it. Please make sure that you are carefully printing out
> > informative logs in either case, to make sure that there is no magic
> > happening that is hidden from users.
> >
> >
> > > Thoughts?
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-3392
> > > On Tue, Jul 24, 2018 at 3:01 PM Vyacheslav Daradur <[hidden email]>
> > > wrote:
> > > >
> > > > Got it.
> > > >
> > > > Yes, we will preserve this behavior.
> > > >
> > > > Thanks!
> > > > On Tue, Jul 24, 2018 at 2:20 PM Dmitriy Setrakyan <[hidden email]>
> > > wrote:
> > > > >
> > > > > By default the client nodes should be excluded form service
> > > deployment. The
> > > > > only way to include clients is to explicitly specify them through node
> > > > > filter. This is how services are deployed today and we should preserve
> > > this
> > > > > behavior.
> > > > >
> > > > > D.
> > > > >
> > > > > On Tue, Jul 24, 2018 at 11:20 AM, Denis Mekhanikov <
> > > [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > Maybe let's keep the functionality the way it is, since it doesn't
> > > > > > interfere with the IEP?
> > > > > >
> > > > > > But I think, it's worth mentioning as a warning in log, that a
> > > service is
> > > > > > deployed on a client node.
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > вт, 24 июл. 2018 г. в 12:44, Vyacheslav Daradur <[hidden email]
> > > >:
> > > > > >
> > > > > > > No, it's doesn't complicate implementation on the current stage.
> > > > > > >
> > > > > > > But we will have to change assignment function to forbid client
> > > nodes
> > > > > > > even if configuration's node filter resolves them it can be not
> > > > > > > transparent for the end user.
> > > > > > >
> > > > > > > I think the only use case to have such behavior is: hosting of not
> > > > > > > collocated services on data free nodes with access to IgniteCaches
> > > on
> > > > > > > remote nodes in the same cluster.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Jul 24, 2018 at 12:10 PM Denis Mekhanikov <
> > > [hidden email]
> > > > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > I don't think, that client nodes, that host services make much
> > > sense.
> > > > > > > > May we forbid it? Does anybody know, when it may be useful?
> > > > > > > >
> > > > > > > > Vyacheslav, does it complicate the implementation somehow?
> > > > > > > >
> > > > > > > > Denis
> > > > > > > >
> > > > > > > > вт, 24 июл. 2018 г. в 11:57, Vyacheslav Daradur <
> > > [hidden email]>:
> > > > > > > >
> > > > > > > > > Hi, Igniters!
> > > > > > > > >
> > > > > > > > > I am close to completing the main tasks and I'm going to
> > > request a
> > > > > > > > > review in a couple weeks.
> > > > > > > > >
> > > > > > > > > I have a question about the new design:
> > > > > > > > >
> > > > > > > > > The current implementation of Service Grid doesn't' take into
> > > account
> > > > > > > > > Ignition#client(true).
> > > > > > > > > It means that *clients* nodes are able to host services. There
> > > are
> > > > > > > > > some tests that expect such behavior.
> > > > > > > > >
> > > > > > > > > Services assignments are managed by a predicate only
> > > > > > > > > (ServiceConfiguration#setNodeFilter(IgnitePredicate<
> > > ClusterNode>).
> > > > > > > > >
> > > > > > > > > Should deployment on clients nodes be forbidden or we
> > > shouldn't mix
> > > > > > > > > concepts for IgniteCache with Service Grid?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Jun 20, 2018 at 1:46 AM Dmitriy Setrakyan <
> > > > > > > [hidden email]>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Jun 19, 2018 at 1:50 PM, Vyacheslav Daradur <
> > > > > > > [hidden email]
> > > > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi Dmitriy,
> > > > > > > > > > >
> > > > > > > > > > > Yes, the task [1] is planned to be implemented once the
> > > main
> > > > > > tasks
> > > > > > > > > > > will be completed.
> > > > > > > > > > >
> > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-8367
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Awesome! This is a huge addition to the project.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Jun 19, 2018 at 10:06 PM Dmitriy Setrakyan
> > > > > > > > > > > <[hidden email]> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Vyacheslav,
> > > > > > > > > > > >
> > > > > > > > > > > > How about service redeployment in case if user wants to
> > > update
> > > > > > > the
> > > > > > > > > code?
> > > > > > > > > > > Is
> > > > > > > > > > > > this planned?
> > > > > > > > > > > >
> > > > > > > > > > > > D.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.

--
Best Regards, Vyacheslav D.

[Denis Mekhanikov]

Vyacheslav,

I think, that this timeout shouldn't be mandatory, and it should be
disabled by default.
We should be ready for long service initialization. So, it shouldn't be
done in any crucial threads like discovery or exchange.

Denis

ср, 25 июл. 2018 г. в 15:59, Vyacheslav Daradur <[hidden email]>:

> FYI, I've filled the tickets:
> https://issues.apache.org/jira/browse/IGNITE-9075
> https://issues.apache.org/jira/browse/IGNITE-9076
> On Wed, Jul 25, 2018 at 12:54 PM Vyacheslav Daradur <[hidden email]>
> wrote:
> >
> > > I think such timeout should be determined on per-service level. Can we
> make
> > > it part of the service configuration, or pass it into deploy method?
> >
> > Agree, per ServiceConfiguration level is more flexible solution.
> >
> > > This is a great question. Will the service be able to continue
> operating
> > > after the cache is destroyed? If not, I would undeploy it
> automatically. If
> > > yes, I would keep it. Please make sure that you are carefully printing
> out
> > > informative logs in either case, to make sure that there is no magic
> > > happening that is hidden from users.
> >
> > A service will be able to work till topology's change after that we
> > have to recalculate assignments and at this moment we won't determine
> > suitable nodes.
> >
> > I will fill new tickets to work on these questions and to implement
> > solutions in the second iteration if nobody doesn't mind.
> > Anyway, it will have been done to a release.
> > On Wed, Jul 25, 2018 at 12:08 PM Dmitriy Setrakyan
> > <[hidden email]> wrote:
> > >
> > > On Tue, Jul 24, 2018 at 9:14 PM, Vyacheslav Daradur <
> [hidden email]>
> > > wrote:
> > >
> > > > Igniters, please help me to clarify the following questions:
> > > >
> > > > 1). According to the issue [1] we should propagate services
> deployment
> > > > results to an initiator, that means we should wait for wor
> > > > Service#init method completion.
> > > > How should we handle Service#init method hangup?
> > > > I propose to introduce some kind of
> > > > IgniteSystemProperties#IGNITE_SERVICE_INIT_TIMEOUT to interrupt long
> > > > initialization.
> > > >
> > >
> > > I think such timeout should be determined on per-service level. Can we
> make
> > > it part of the service configuration, or pass it into deploy method?
> > >
> > >
> > > > 2) Should we automatically undeploy services, which had been deployed
> > > > using #deployKeyAffinitySingleton, on destroying of related
> IgniteCache?
> > > >
> > > >
> > > This is a great question. Will the service be able to continue
> operating
> > > after the cache is destroyed? If not, I would undeploy it
> automatically. If
> > > yes, I would keep it. Please make sure that you are carefully printing
> out
> > > informative logs in either case, to make sure that there is no magic
> > > happening that is hidden from users.
> > >
> > >
> > > > Thoughts?
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-3392
> > > > On Tue, Jul 24, 2018 at 3:01 PM Vyacheslav Daradur <
> [hidden email]>
> > > > wrote:
> > > > >
> > > > > Got it.
> > > > >
> > > > > Yes, we will preserve this behavior.
> > > > >
> > > > > Thanks!
> > > > > On Tue, Jul 24, 2018 at 2:20 PM Dmitriy Setrakyan <
> [hidden email]>
> > > > wrote:
> > > > > >
> > > > > > By default the client nodes should be excluded form service
> > > > deployment. The
> > > > > > only way to include clients is to explicitly specify them
> through node
> > > > > > filter. This is how services are deployed today and we should
> preserve
> > > > this
> > > > > > behavior.
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Tue, Jul 24, 2018 at 11:20 AM, Denis Mekhanikov <
> > > > [hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > > > Maybe let's keep the functionality the way it is, since it
> doesn't
> > > > > > > interfere with the IEP?
> > > > > > >
> > > > > > > But I think, it's worth mentioning as a warning in log, that a
> > > > service is
> > > > > > > deployed on a client node.
> > > > > > >
> > > > > > > Denis
> > > > > > >
> > > > > > > вт, 24 июл. 2018 г. в 12:44, Vyacheslav Daradur <
> [hidden email]
> > > > >:
> > > > > > >
> > > > > > > > No, it's doesn't complicate implementation on the current
> stage.
> > > > > > > >
> > > > > > > > But we will have to change assignment function to forbid
> client
> > > > nodes
> > > > > > > > even if configuration's node filter resolves them it can be
> not
> > > > > > > > transparent for the end user.
> > > > > > > >
> > > > > > > > I think the only use case to have such behavior is: hosting
> of not
> > > > > > > > collocated services on data free nodes with access to
> IgniteCaches
> > > > on
> > > > > > > > remote nodes in the same cluster.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Jul 24, 2018 at 12:10 PM Denis Mekhanikov <
> > > > [hidden email]
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > I don't think, that client nodes, that host services make
> much
> > > > sense.
> > > > > > > > > May we forbid it? Does anybody know, when it may be useful?
> > > > > > > > >
> > > > > > > > > Vyacheslav, does it complicate the implementation somehow?
> > > > > > > > >
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > вт, 24 июл. 2018 г. в 11:57, Vyacheslav Daradur <
> > > > [hidden email]>:
> > > > > > > > >
> > > > > > > > > > Hi, Igniters!
> > > > > > > > > >
> > > > > > > > > > I am close to completing the main tasks and I'm going to
> > > > request a
> > > > > > > > > > review in a couple weeks.
> > > > > > > > > >
> > > > > > > > > > I have a question about the new design:
> > > > > > > > > >
> > > > > > > > > > The current implementation of Service Grid doesn't' take
> into
> > > > account
> > > > > > > > > > Ignition#client(true).
> > > > > > > > > > It means that *clients* nodes are able to host services.
> There
> > > > are
> > > > > > > > > > some tests that expect such behavior.
> > > > > > > > > >
> > > > > > > > > > Services assignments are managed by a predicate only
> > > > > > > > > > (ServiceConfiguration#setNodeFilter(IgnitePredicate<
> > > > ClusterNode>).
> > > > > > > > > >
> > > > > > > > > > Should deployment on clients nodes be forbidden or we
> > > > shouldn't mix
> > > > > > > > > > concepts for IgniteCache with Service Grid?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Jun 20, 2018 at 1:46 AM Dmitriy Setrakyan <
> > > > > > > > [hidden email]>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Jun 19, 2018 at 1:50 PM, Vyacheslav Daradur <
> > > > > > > > [hidden email]
> > > > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Dmitriy,
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, the task [1] is planned to be implemented once
> the
> > > > main
> > > > > > > tasks
> > > > > > > > > > > > will be completed.
> > > > > > > > > > > >
> > > > > > > > > > > > [1]
> https://issues.apache.org/jira/browse/IGNITE-8367
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Awesome! This is a huge addition to the project.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Jun 19, 2018 at 10:06 PM Dmitriy Setrakyan
> > > > > > > > > > > > <[hidden email]> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Vyacheslav,
> > > > > > > > > > > > >
> > > > > > > > > > > > > How about service redeployment in case if user
> wants to
> > > > update
> > > > > > > > the
> > > > > > > > > > code?
> > > > > > > > > > > > Is
> > > > > > > > > > > > > this planned?
> > > > > > > > > > > > >
> > > > > > > > > > > > > D.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
>
>
>
> --
> Best Regards, Vyacheslav D.
>

[daradurvs]

Denis, long service initialization isn't a big problem for us.

The problem is hung initialization, that means the service deployment
will never complete.
On Wed, Jul 25, 2018 at 8:08 PM Denis Mekhanikov <[hidden email]> wrote:

>
> Vyacheslav,
>
> I think, that this timeout shouldn't be mandatory, and it should be
> disabled by default.
> We should be ready for long service initialization. So, it shouldn't be
> done in any crucial threads like discovery or exchange.
>
> Denis
>
> ср, 25 июл. 2018 г. в 15:59, Vyacheslav Daradur <[hidden email]>:
>
> > FYI, I've filled the tickets:
> > https://issues.apache.org/jira/browse/IGNITE-9075
> > https://issues.apache.org/jira/browse/IGNITE-9076
> > On Wed, Jul 25, 2018 at 12:54 PM Vyacheslav Daradur <[hidden email]>
> > wrote:
> > >
> > > > I think such timeout should be determined on per-service level. Can we
> > make
> > > > it part of the service configuration, or pass it into deploy method?
> > >
> > > Agree, per ServiceConfiguration level is more flexible solution.
> > >
> > > > This is a great question. Will the service be able to continue
> > operating
> > > > after the cache is destroyed? If not, I would undeploy it
> > automatically. If
> > > > yes, I would keep it. Please make sure that you are carefully printing
> > out
> > > > informative logs in either case, to make sure that there is no magic
> > > > happening that is hidden from users.
> > >
> > > A service will be able to work till topology's change after that we
> > > have to recalculate assignments and at this moment we won't determine
> > > suitable nodes.
> > >
> > > I will fill new tickets to work on these questions and to implement
> > > solutions in the second iteration if nobody doesn't mind.
> > > Anyway, it will have been done to a release.
> > > On Wed, Jul 25, 2018 at 12:08 PM Dmitriy Setrakyan
> > > <[hidden email]> wrote:
> > > >
> > > > On Tue, Jul 24, 2018 at 9:14 PM, Vyacheslav Daradur <
> > [hidden email]>
> > > > wrote:
> > > >
> > > > > Igniters, please help me to clarify the following questions:
> > > > >
> > > > > 1). According to the issue [1] we should propagate services
> > deployment
> > > > > results to an initiator, that means we should wait for wor
> > > > > Service#init method completion.
> > > > > How should we handle Service#init method hangup?
> > > > > I propose to introduce some kind of
> > > > > IgniteSystemProperties#IGNITE_SERVICE_INIT_TIMEOUT to interrupt long
> > > > > initialization.
> > > > >
> > > >
> > > > I think such timeout should be determined on per-service level. Can we
> > make
> > > > it part of the service configuration, or pass it into deploy method?
> > > >
> > > >
> > > > > 2) Should we automatically undeploy services, which had been deployed
> > > > > using #deployKeyAffinitySingleton, on destroying of related
> > IgniteCache?
> > > > >
> > > > >
> > > > This is a great question. Will the service be able to continue
> > operating
> > > > after the cache is destroyed? If not, I would undeploy it
> > automatically. If
> > > > yes, I would keep it. Please make sure that you are carefully printing
> > out
> > > > informative logs in either case, to make sure that there is no magic
> > > > happening that is hidden from users.
> > > >
> > > >
> > > > > Thoughts?
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-3392
> > > > > On Tue, Jul 24, 2018 at 3:01 PM Vyacheslav Daradur <
> > [hidden email]>
> > > > > wrote:
> > > > > >
> > > > > > Got it.
> > > > > >
> > > > > > Yes, we will preserve this behavior.
> > > > > >
> > > > > > Thanks!
> > > > > > On Tue, Jul 24, 2018 at 2:20 PM Dmitriy Setrakyan <
> > [hidden email]>
> > > > > wrote:
> > > > > > >
> > > > > > > By default the client nodes should be excluded form service
> > > > > deployment. The
> > > > > > > only way to include clients is to explicitly specify them
> > through node
> > > > > > > filter. This is how services are deployed today and we should
> > preserve
> > > > > this
> > > > > > > behavior.
> > > > > > >
> > > > > > > D.
> > > > > > >
> > > > > > > On Tue, Jul 24, 2018 at 11:20 AM, Denis Mekhanikov <
> > > > > [hidden email]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Maybe let's keep the functionality the way it is, since it
> > doesn't
> > > > > > > > interfere with the IEP?
> > > > > > > >
> > > > > > > > But I think, it's worth mentioning as a warning in log, that a
> > > > > service is
> > > > > > > > deployed on a client node.
> > > > > > > >
> > > > > > > > Denis
> > > > > > > >
> > > > > > > > вт, 24 июл. 2018 г. в 12:44, Vyacheslav Daradur <
> > [hidden email]
> > > > > >:
> > > > > > > >
> > > > > > > > > No, it's doesn't complicate implementation on the current
> > stage.
> > > > > > > > >
> > > > > > > > > But we will have to change assignment function to forbid
> > client
> > > > > nodes
> > > > > > > > > even if configuration's node filter resolves them it can be
> > not
> > > > > > > > > transparent for the end user.
> > > > > > > > >
> > > > > > > > > I think the only use case to have such behavior is: hosting
> > of not
> > > > > > > > > collocated services on data free nodes with access to
> > IgniteCaches
> > > > > on
> > > > > > > > > remote nodes in the same cluster.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Jul 24, 2018 at 12:10 PM Denis Mekhanikov <
> > > > > [hidden email]
> > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > I don't think, that client nodes, that host services make
> > much
> > > > > sense.
> > > > > > > > > > May we forbid it? Does anybody know, when it may be useful?
> > > > > > > > > >
> > > > > > > > > > Vyacheslav, does it complicate the implementation somehow?
> > > > > > > > > >
> > > > > > > > > > Denis
> > > > > > > > > >
> > > > > > > > > > вт, 24 июл. 2018 г. в 11:57, Vyacheslav Daradur <
> > > > > [hidden email]>:
> > > > > > > > > >
> > > > > > > > > > > Hi, Igniters!
> > > > > > > > > > >
> > > > > > > > > > > I am close to completing the main tasks and I'm going to
> > > > > request a
> > > > > > > > > > > review in a couple weeks.
> > > > > > > > > > >
> > > > > > > > > > > I have a question about the new design:
> > > > > > > > > > >
> > > > > > > > > > > The current implementation of Service Grid doesn't' take
> > into
> > > > > account
> > > > > > > > > > > Ignition#client(true).
> > > > > > > > > > > It means that *clients* nodes are able to host services.
> > There
> > > > > are
> > > > > > > > > > > some tests that expect such behavior.
> > > > > > > > > > >
> > > > > > > > > > > Services assignments are managed by a predicate only
> > > > > > > > > > > (ServiceConfiguration#setNodeFilter(IgnitePredicate<
> > > > > ClusterNode>).
> > > > > > > > > > >
> > > > > > > > > > > Should deployment on clients nodes be forbidden or we
> > > > > shouldn't mix
> > > > > > > > > > > concepts for IgniteCache with Service Grid?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Jun 20, 2018 at 1:46 AM Dmitriy Setrakyan <
> > > > > > > > > [hidden email]>
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Jun 19, 2018 at 1:50 PM, Vyacheslav Daradur <
> > > > > > > > > [hidden email]
> > > > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi Dmitriy,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, the task [1] is planned to be implemented once
> > the
> > > > > main
> > > > > > > > tasks
> > > > > > > > > > > > > will be completed.
> > > > > > > > > > > > >
> > > > > > > > > > > > > [1]
> > https://issues.apache.org/jira/browse/IGNITE-8367
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Awesome! This is a huge addition to the project.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Jun 19, 2018 at 10:06 PM Dmitriy Setrakyan
> > > > > > > > > > > > > <[hidden email]> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Vyacheslav,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > How about service redeployment in case if user
> > wants to
> > > > > update
> > > > > > > > > the
> > > > > > > > > > > code?
> > > > > > > > > > > > > Is
> > > > > > > > > > > > > > this planned?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > D.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >

--
Best Regards, Vyacheslav D.

[Anton Vinogradov-2]

Folks,

I don't think that it's a good idea to host services on client nodes.
Client topology is not stable enough, and I don't see how to guarantee
availability of such services.
We'll have huge problems to guarantee availability in case of blinking
clients.

Also, taking into account that ignite cluster can have more that one user
it looks odd that one user able to start service at another user's hardware
(bitcoin miners can be disagree with me).

In case you want to use nodes only to host services - all you need is to
filter them from cache affinity functions.

I propose to implement Services pretty close to Cache implementation.
It's a bad idea to reinvent the weel there.
Let's just analyse Cache's code and do the same for services with same
guarantee.

ср, 25 июл. 2018 г. в 21:58, Vyacheslav Daradur <[hidden email]>:

> Denis, long service initialization isn't a big problem for us.
>
> The problem is hung initialization, that means the service deployment
> will never complete.
> On Wed, Jul 25, 2018 at 8:08 PM Denis Mekhanikov <[hidden email]>
> wrote:
> >
> > Vyacheslav,
> >
> > I think, that this timeout shouldn't be mandatory, and it should be
> > disabled by default.
> > We should be ready for long service initialization. So, it shouldn't be
> > done in any crucial threads like discovery or exchange.
> >
> > Denis
> >
> > ср, 25 июл. 2018 г. в 15:59, Vyacheslav Daradur <[hidden email]>:
> >
> > > FYI, I've filled the tickets:
> > > https://issues.apache.org/jira/browse/IGNITE-9075
> > > https://issues.apache.org/jira/browse/IGNITE-9076
> > > On Wed, Jul 25, 2018 at 12:54 PM Vyacheslav Daradur <
> [hidden email]>
> > > wrote:
> > > >
> > > > > I think such timeout should be determined on per-service level.
> Can we
> > > make
> > > > > it part of the service configuration, or pass it into deploy
> method?
> > > >
> > > > Agree, per ServiceConfiguration level is more flexible solution.
> > > >
> > > > > This is a great question. Will the service be able to continue
> > > operating
> > > > > after the cache is destroyed? If not, I would undeploy it
> > > automatically. If
> > > > > yes, I would keep it. Please make sure that you are carefully
> printing
> > > out
> > > > > informative logs in either case, to make sure that there is no
> magic
> > > > > happening that is hidden from users.
> > > >
> > > > A service will be able to work till topology's change after that we
> > > > have to recalculate assignments and at this moment we won't determine
> > > > suitable nodes.
> > > >
> > > > I will fill new tickets to work on these questions and to implement
> > > > solutions in the second iteration if nobody doesn't mind.
> > > > Anyway, it will have been done to a release.
> > > > On Wed, Jul 25, 2018 at 12:08 PM Dmitriy Setrakyan
> > > > <[hidden email]> wrote:
> > > > >
> > > > > On Tue, Jul 24, 2018 at 9:14 PM, Vyacheslav Daradur <
> > > [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > Igniters, please help me to clarify the following questions:
> > > > > >
> > > > > > 1). According to the issue [1] we should propagate services
> > > deployment
> > > > > > results to an initiator, that means we should wait for wor
> > > > > > Service#init method completion.
> > > > > > How should we handle Service#init method hangup?
> > > > > > I propose to introduce some kind of
> > > > > > IgniteSystemProperties#IGNITE_SERVICE_INIT_TIMEOUT to interrupt
> long
> > > > > > initialization.
> > > > > >
> > > > >
> > > > > I think such timeout should be determined on per-service level.
> Can we
> > > make
> > > > > it part of the service configuration, or pass it into deploy
> method?
> > > > >
> > > > >
> > > > > > 2) Should we automatically undeploy services, which had been
> deployed
> > > > > > using #deployKeyAffinitySingleton, on destroying of related
> > > IgniteCache?
> > > > > >
> > > > > >
> > > > > This is a great question. Will the service be able to continue
> > > operating
> > > > > after the cache is destroyed? If not, I would undeploy it
> > > automatically. If
> > > > > yes, I would keep it. Please make sure that you are carefully
> printing
> > > out
> > > > > informative logs in either case, to make sure that there is no
> magic
> > > > > happening that is hidden from users.
> > > > >
> > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-3392
> > > > > > On Tue, Jul 24, 2018 at 3:01 PM Vyacheslav Daradur <
> > > [hidden email]>
> > > > > > wrote:
> > > > > > >
> > > > > > > Got it.
> > > > > > >
> > > > > > > Yes, we will preserve this behavior.
> > > > > > >
> > > > > > > Thanks!
> > > > > > > On Tue, Jul 24, 2018 at 2:20 PM Dmitriy Setrakyan <
> > > [hidden email]>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > By default the client nodes should be excluded form service
> > > > > > deployment. The
> > > > > > > > only way to include clients is to explicitly specify them
> > > through node
> > > > > > > > filter. This is how services are deployed today and we should
> > > preserve
> > > > > > this
> > > > > > > > behavior.
> > > > > > > >
> > > > > > > > D.
> > > > > > > >
> > > > > > > > On Tue, Jul 24, 2018 at 11:20 AM, Denis Mekhanikov <
> > > > > > [hidden email]>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Maybe let's keep the functionality the way it is, since it
> > > doesn't
> > > > > > > > > interfere with the IEP?
> > > > > > > > >
> > > > > > > > > But I think, it's worth mentioning as a warning in log,
> that a
> > > > > > service is
> > > > > > > > > deployed on a client node.
> > > > > > > > >
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > вт, 24 июл. 2018 г. в 12:44, Vyacheslav Daradur <
> > > [hidden email]
> > > > > > >:
> > > > > > > > >
> > > > > > > > > > No, it's doesn't complicate implementation on the current
> > > stage.
> > > > > > > > > >
> > > > > > > > > > But we will have to change assignment function to forbid
> > > client
> > > > > > nodes
> > > > > > > > > > even if configuration's node filter resolves them it can
> be
> > > not
> > > > > > > > > > transparent for the end user.
> > > > > > > > > >
> > > > > > > > > > I think the only use case to have such behavior is:
> hosting
> > > of not
> > > > > > > > > > collocated services on data free nodes with access to
> > > IgniteCaches
> > > > > > on
> > > > > > > > > > remote nodes in the same cluster.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, Jul 24, 2018 at 12:10 PM Denis Mekhanikov <
> > > > > > [hidden email]
> > > > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > I don't think, that client nodes, that host services
> make
> > > much
> > > > > > sense.
> > > > > > > > > > > May we forbid it? Does anybody know, when it may be
> useful?
> > > > > > > > > > >
> > > > > > > > > > > Vyacheslav, does it complicate the implementation
> somehow?
> > > > > > > > > > >
> > > > > > > > > > > Denis
> > > > > > > > > > >
> > > > > > > > > > > вт, 24 июл. 2018 г. в 11:57, Vyacheslav Daradur <
> > > > > > [hidden email]>:
> > > > > > > > > > >
> > > > > > > > > > > > Hi, Igniters!
> > > > > > > > > > > >
> > > > > > > > > > > > I am close to completing the main tasks and I'm
> going to
> > > > > > request a
> > > > > > > > > > > > review in a couple weeks.
> > > > > > > > > > > >
> > > > > > > > > > > > I have a question about the new design:
> > > > > > > > > > > >
> > > > > > > > > > > > The current implementation of Service Grid doesn't'
> take
> > > into
> > > > > > account
> > > > > > > > > > > > Ignition#client(true).
> > > > > > > > > > > > It means that *clients* nodes are able to host
> services.
> > > There
> > > > > > are
> > > > > > > > > > > > some tests that expect such behavior.
> > > > > > > > > > > >
> > > > > > > > > > > > Services assignments are managed by a predicate only
> > > > > > > > > > > > (ServiceConfiguration#setNodeFilter(IgnitePredicate<
> > > > > > ClusterNode>).
> > > > > > > > > > > >
> > > > > > > > > > > > Should deployment on clients nodes be forbidden or we
> > > > > > shouldn't mix
> > > > > > > > > > > > concepts for IgniteCache with Service Grid?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Jun 20, 2018 at 1:46 AM Dmitriy Setrakyan <
> > > > > > > > > > [hidden email]>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Jun 19, 2018 at 1:50 PM, Vyacheslav
> Daradur <
> > > > > > > > > > [hidden email]
> > > > > > > > > > > > >
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Dmitriy,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, the task [1] is planned to be implemented
> once
> > > the
> > > > > > main
> > > > > > > > > tasks
> > > > > > > > > > > > > > will be completed.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > [1]
> > > https://issues.apache.org/jira/browse/IGNITE-8367
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Awesome! This is a huge addition to the project.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Jun 19, 2018 at 10:06 PM Dmitriy
> Setrakyan
> > > > > > > > > > > > > > <[hidden email]> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Vyacheslav,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > How about service redeployment in case if user
> > > wants to
> > > > > > update
> > > > > > > > > > the
> > > > > > > > > > > > code?
> > > > > > > > > > > > > > Is
> > > > > > > > > > > > > > > this planned?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > D.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

[Denis Mekhanikov]

Anton,

I believe, there are cases, when people want to have node singleton
services, that are deployed to clients, as well as to all other nodes.
And currently clients can execute compute jobs, issued by other clients,
and services are not very different from them.
Clients may store data and run code. We shouldn't consider them as
"end-user nodes". Only thin clients should be run by end users.

But I agree, that we shouldn't encourage people to use services this way.
So, if it doesn't complicate the implementation too much, then a warning in
log will be enough, I think.

Denis

чт, 26 июл. 2018 г. в 19:56, Anton Vinogradov <[hidden email]>:

> Folks,
>
> I don't think that it's a good idea to host services on client nodes.
> Client topology is not stable enough, and I don't see how to guarantee
> availability of such services.
> We'll have huge problems to guarantee availability in case of blinking
> clients.
>
> Also, taking into account that ignite cluster can have more that one user
> it looks odd that one user able to start service at another user's hardware
> (bitcoin miners can be disagree with me).
>
> In case you want to use nodes only to host services - all you need is to
> filter them from cache affinity functions.
>
> I propose to implement Services pretty close to Cache implementation.
> It's a bad idea to reinvent the weel there.
> Let's just analyse Cache's code and do the same for services with same
> guarantee.
>
> ср, 25 июл. 2018 г. в 21:58, Vyacheslav Daradur <[hidden email]>:
>
> > Denis, long service initialization isn't a big problem for us.
> >
> > The problem is hung initialization, that means the service deployment
> > will never complete.
> > On Wed, Jul 25, 2018 at 8:08 PM Denis Mekhanikov <[hidden email]>
> > wrote:
> > >
> > > Vyacheslav,
> > >
> > > I think, that this timeout shouldn't be mandatory, and it should be
> > > disabled by default.
> > > We should be ready for long service initialization. So, it shouldn't be
> > > done in any crucial threads like discovery or exchange.
> > >
> > > Denis
> > >
> > > ср, 25 июл. 2018 г. в 15:59, Vyacheslav Daradur <[hidden email]>:
> > >
> > > > FYI, I've filled the tickets:
> > > > https://issues.apache.org/jira/browse/IGNITE-9075
> > > > https://issues.apache.org/jira/browse/IGNITE-9076
> > > > On Wed, Jul 25, 2018 at 12:54 PM Vyacheslav Daradur <
> > [hidden email]>
> > > > wrote:
> > > > >
> > > > > > I think such timeout should be determined on per-service level.
> > Can we
> > > > make
> > > > > > it part of the service configuration, or pass it into deploy
> > method?
> > > > >
> > > > > Agree, per ServiceConfiguration level is more flexible solution.
> > > > >
> > > > > > This is a great question. Will the service be able to continue
> > > > operating
> > > > > > after the cache is destroyed? If not, I would undeploy it
> > > > automatically. If
> > > > > > yes, I would keep it. Please make sure that you are carefully
> > printing
> > > > out
> > > > > > informative logs in either case, to make sure that there is no
> > magic
> > > > > > happening that is hidden from users.
> > > > >
> > > > > A service will be able to work till topology's change after that we
> > > > > have to recalculate assignments and at this moment we won't
> determine
> > > > > suitable nodes.
> > > > >
> > > > > I will fill new tickets to work on these questions and to implement
> > > > > solutions in the second iteration if nobody doesn't mind.
> > > > > Anyway, it will have been done to a release.
> > > > > On Wed, Jul 25, 2018 at 12:08 PM Dmitriy Setrakyan
> > > > > <[hidden email]> wrote:
> > > > > >
> > > > > > On Tue, Jul 24, 2018 at 9:14 PM, Vyacheslav Daradur <
> > > > [hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > > > Igniters, please help me to clarify the following questions:
> > > > > > >
> > > > > > > 1). According to the issue [1] we should propagate services
> > > > deployment
> > > > > > > results to an initiator, that means we should wait for wor
> > > > > > > Service#init method completion.
> > > > > > > How should we handle Service#init method hangup?
> > > > > > > I propose to introduce some kind of
> > > > > > > IgniteSystemProperties#IGNITE_SERVICE_INIT_TIMEOUT to interrupt
> > long
> > > > > > > initialization.
> > > > > > >
> > > > > >
> > > > > > I think such timeout should be determined on per-service level.
> > Can we
> > > > make
> > > > > > it part of the service configuration, or pass it into deploy
> > method?
> > > > > >
> > > > > >
> > > > > > > 2) Should we automatically undeploy services, which had been
> > deployed
> > > > > > > using #deployKeyAffinitySingleton, on destroying of related
> > > > IgniteCache?
> > > > > > >
> > > > > > >
> > > > > > This is a great question. Will the service be able to continue
> > > > operating
> > > > > > after the cache is destroyed? If not, I would undeploy it
> > > > automatically. If
> > > > > > yes, I would keep it. Please make sure that you are carefully
> > printing
> > > > out
> > > > > > informative logs in either case, to make sure that there is no
> > magic
> > > > > > happening that is hidden from users.
> > > > > >
> > > > > >
> > > > > > > Thoughts?
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-3392
> > > > > > > On Tue, Jul 24, 2018 at 3:01 PM Vyacheslav Daradur <
> > > > [hidden email]>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Got it.
> > > > > > > >
> > > > > > > > Yes, we will preserve this behavior.
> > > > > > > >
> > > > > > > > Thanks!
> > > > > > > > On Tue, Jul 24, 2018 at 2:20 PM Dmitriy Setrakyan <
> > > > [hidden email]>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > By default the client nodes should be excluded form service
> > > > > > > deployment. The
> > > > > > > > > only way to include clients is to explicitly specify them
> > > > through node
> > > > > > > > > filter. This is how services are deployed today and we
> should
> > > > preserve
> > > > > > > this
> > > > > > > > > behavior.
> > > > > > > > >
> > > > > > > > > D.
> > > > > > > > >
> > > > > > > > > On Tue, Jul 24, 2018 at 11:20 AM, Denis Mekhanikov <
> > > > > > > [hidden email]>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Maybe let's keep the functionality the way it is, since
> it
> > > > doesn't
> > > > > > > > > > interfere with the IEP?
> > > > > > > > > >
> > > > > > > > > > But I think, it's worth mentioning as a warning in log,
> > that a
> > > > > > > service is
> > > > > > > > > > deployed on a client node.
> > > > > > > > > >
> > > > > > > > > > Denis
> > > > > > > > > >
> > > > > > > > > > вт, 24 июл. 2018 г. в 12:44, Vyacheslav Daradur <
> > > > [hidden email]
> > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > No, it's doesn't complicate implementation on the
> current
> > > > stage.
> > > > > > > > > > >
> > > > > > > > > > > But we will have to change assignment function to
> forbid
> > > > client
> > > > > > > nodes
> > > > > > > > > > > even if configuration's node filter resolves them it
> can
> > be
> > > > not
> > > > > > > > > > > transparent for the end user.
> > > > > > > > > > >
> > > > > > > > > > > I think the only use case to have such behavior is:
> > hosting
> > > > of not
> > > > > > > > > > > collocated services on data free nodes with access to
> > > > IgniteCaches
> > > > > > > on
> > > > > > > > > > > remote nodes in the same cluster.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Jul 24, 2018 at 12:10 PM Denis Mekhanikov <
> > > > > > > [hidden email]
> > > > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > I don't think, that client nodes, that host services
> > make
> > > > much
> > > > > > > sense.
> > > > > > > > > > > > May we forbid it? Does anybody know, when it may be
> > useful?
> > > > > > > > > > > >
> > > > > > > > > > > > Vyacheslav, does it complicate the implementation
> > somehow?
> > > > > > > > > > > >
> > > > > > > > > > > > Denis
> > > > > > > > > > > >
> > > > > > > > > > > > вт, 24 июл. 2018 г. в 11:57, Vyacheslav Daradur <
> > > > > > > [hidden email]>:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi, Igniters!
> > > > > > > > > > > > >
> > > > > > > > > > > > > I am close to completing the main tasks and I'm
> > going to
> > > > > > > request a
> > > > > > > > > > > > > review in a couple weeks.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I have a question about the new design:
> > > > > > > > > > > > >
> > > > > > > > > > > > > The current implementation of Service Grid doesn't'
> > take
> > > > into
> > > > > > > account
> > > > > > > > > > > > > Ignition#client(true).
> > > > > > > > > > > > > It means that *clients* nodes are able to host
> > services.
> > > > There
> > > > > > > are
> > > > > > > > > > > > > some tests that expect such behavior.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Services assignments are managed by a predicate
> only
> > > > > > > > > > > > >
> (ServiceConfiguration#setNodeFilter(IgnitePredicate<
> > > > > > > ClusterNode>).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Should deployment on clients nodes be forbidden or
> we
> > > > > > > shouldn't mix
> > > > > > > > > > > > > concepts for IgniteCache with Service Grid?
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Jun 20, 2018 at 1:46 AM Dmitriy Setrakyan <
> > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Jun 19, 2018 at 1:50 PM, Vyacheslav
> > Daradur <
> > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Dmitriy,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes, the task [1] is planned to be implemented
> > once
> > > > the
> > > > > > > main
> > > > > > > > > > tasks
> > > > > > > > > > > > > > > will be completed.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > [1]
> > > > https://issues.apache.org/jira/browse/IGNITE-8367
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Awesome! This is a huge addition to the project.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, Jun 19, 2018 at 10:06 PM Dmitriy
> > Setrakyan
> > > > > > > > > > > > > > > <[hidden email]> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Vyacheslav,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > How about service redeployment in case if
> user
> > > > wants to
> > > > > > > update
> > > > > > > > > > > the
> > > > > > > > > > > > > code?
> > > > > > > > > > > > > > > Is
> > > > > > > > > > > > > > > > this planned?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > D.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

[Anton Vinogradov-2]

Denis,

Main features of Ignite Cache are availability and throughput.

I'd like to refactor Serviсe Grid to be the same.
Main feature should be guarantee of availability and throughput (instance
count).

Client should ask grid to execute the service, that's all. No matter how
grid will do this.
This should be like cache 'put' or 'get' call.

In case you want to execute something locally you should just implement it
inside your application rather than deploy it to Ignite Cluster.
There are absolutely no reason to mix local services and Service Grid.

P.s. As for me, all "local" features should be deprecated, since we're
distributed.

чт, 26 июл. 2018 г. в 21:13, Denis Mekhanikov <[hidden email]>:

> Anton,
>
> I believe, there are cases, when people want to have node singleton
> services, that are deployed to clients, as well as to all other nodes.
> And currently clients can execute compute jobs, issued by other clients,
> and services are not very different from them.
> Clients may store data and run code. We shouldn't consider them as
> "end-user nodes". Only thin clients should be run by end users.
>
> But I agree, that we shouldn't encourage people to use services this way.
> So, if it doesn't complicate the implementation too much, then a warning in
> log will be enough, I think.
>
> Denis
>
> чт, 26 июл. 2018 г. в 19:56, Anton Vinogradov <[hidden email]>:
>
> > Folks,
> >
> > I don't think that it's a good idea to host services on client nodes.
> > Client topology is not stable enough, and I don't see how to guarantee
> > availability of such services.
> > We'll have huge problems to guarantee availability in case of blinking
> > clients.
> >
> > Also, taking into account that ignite cluster can have more that one user
> > it looks odd that one user able to start service at another user's
> hardware
> > (bitcoin miners can be disagree with me).
> >
> > In case you want to use nodes only to host services - all you need is to
> > filter them from cache affinity functions.
> >
> > I propose to implement Services pretty close to Cache implementation.
> > It's a bad idea to reinvent the weel there.
> > Let's just analyse Cache's code and do the same for services with same
> > guarantee.
> >
> > ср, 25 июл. 2018 г. в 21:58, Vyacheslav Daradur <[hidden email]>:
> >
> > > Denis, long service initialization isn't a big problem for us.
> > >
> > > The problem is hung initialization, that means the service deployment
> > > will never complete.
> > > On Wed, Jul 25, 2018 at 8:08 PM Denis Mekhanikov <
> [hidden email]>
> > > wrote:
> > > >
> > > > Vyacheslav,
> > > >
> > > > I think, that this timeout shouldn't be mandatory, and it should be
> > > > disabled by default.
> > > > We should be ready for long service initialization. So, it shouldn't
> be
> > > > done in any crucial threads like discovery or exchange.
> > > >
> > > > Denis
> > > >
> > > > ср, 25 июл. 2018 г. в 15:59, Vyacheslav Daradur <[hidden email]
> >:
> > > >
> > > > > FYI, I've filled the tickets:
> > > > > https://issues.apache.org/jira/browse/IGNITE-9075
> > > > > https://issues.apache.org/jira/browse/IGNITE-9076
> > > > > On Wed, Jul 25, 2018 at 12:54 PM Vyacheslav Daradur <
> > > [hidden email]>
> > > > > wrote:
> > > > > >
> > > > > > > I think such timeout should be determined on per-service level.
> > > Can we
> > > > > make
> > > > > > > it part of the service configuration, or pass it into deploy
> > > method?
> > > > > >
> > > > > > Agree, per ServiceConfiguration level is more flexible solution.
> > > > > >
> > > > > > > This is a great question. Will the service be able to continue
> > > > > operating
> > > > > > > after the cache is destroyed? If not, I would undeploy it
> > > > > automatically. If
> > > > > > > yes, I would keep it. Please make sure that you are carefully
> > > printing
> > > > > out
> > > > > > > informative logs in either case, to make sure that there is no
> > > magic
> > > > > > > happening that is hidden from users.
> > > > > >
> > > > > > A service will be able to work till topology's change after that
> we
> > > > > > have to recalculate assignments and at this moment we won't
> > determine
> > > > > > suitable nodes.
> > > > > >
> > > > > > I will fill new tickets to work on these questions and to
> implement
> > > > > > solutions in the second iteration if nobody doesn't mind.
> > > > > > Anyway, it will have been done to a release.
> > > > > > On Wed, Jul 25, 2018 at 12:08 PM Dmitriy Setrakyan
> > > > > > <[hidden email]> wrote:
> > > > > > >
> > > > > > > On Tue, Jul 24, 2018 at 9:14 PM, Vyacheslav Daradur <
> > > > > [hidden email]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Igniters, please help me to clarify the following questions:
> > > > > > > >
> > > > > > > > 1). According to the issue [1] we should propagate services
> > > > > deployment
> > > > > > > > results to an initiator, that means we should wait for wor
> > > > > > > > Service#init method completion.
> > > > > > > > How should we handle Service#init method hangup?
> > > > > > > > I propose to introduce some kind of
> > > > > > > > IgniteSystemProperties#IGNITE_SERVICE_INIT_TIMEOUT to
> interrupt
> > > long
> > > > > > > > initialization.
> > > > > > > >
> > > > > > >
> > > > > > > I think such timeout should be determined on per-service level.
> > > Can we
> > > > > make
> > > > > > > it part of the service configuration, or pass it into deploy
> > > method?
> > > > > > >
> > > > > > >
> > > > > > > > 2) Should we automatically undeploy services, which had been
> > > deployed
> > > > > > > > using #deployKeyAffinitySingleton, on destroying of related
> > > > > IgniteCache?
> > > > > > > >
> > > > > > > >
> > > > > > > This is a great question. Will the service be able to continue
> > > > > operating
> > > > > > > after the cache is destroyed? If not, I would undeploy it
> > > > > automatically. If
> > > > > > > yes, I would keep it. Please make sure that you are carefully
> > > printing
> > > > > out
> > > > > > > informative logs in either case, to make sure that there is no
> > > magic
> > > > > > > happening that is hidden from users.
> > > > > > >
> > > > > > >
> > > > > > > > Thoughts?
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-3392
> > > > > > > > On Tue, Jul 24, 2018 at 3:01 PM Vyacheslav Daradur <
> > > > > [hidden email]>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Got it.
> > > > > > > > >
> > > > > > > > > Yes, we will preserve this behavior.
> > > > > > > > >
> > > > > > > > > Thanks!
> > > > > > > > > On Tue, Jul 24, 2018 at 2:20 PM Dmitriy Setrakyan <
> > > > > [hidden email]>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > By default the client nodes should be excluded form
> service
> > > > > > > > deployment. The
> > > > > > > > > > only way to include clients is to explicitly specify them
> > > > > through node
> > > > > > > > > > filter. This is how services are deployed today and we
> > should
> > > > > preserve
> > > > > > > > this
> > > > > > > > > > behavior.
> > > > > > > > > >
> > > > > > > > > > D.
> > > > > > > > > >
> > > > > > > > > > On Tue, Jul 24, 2018 at 11:20 AM, Denis Mekhanikov <
> > > > > > > > [hidden email]>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Maybe let's keep the functionality the way it is, since
> > it
> > > > > doesn't
> > > > > > > > > > > interfere with the IEP?
> > > > > > > > > > >
> > > > > > > > > > > But I think, it's worth mentioning as a warning in log,
> > > that a
> > > > > > > > service is
> > > > > > > > > > > deployed on a client node.
> > > > > > > > > > >
> > > > > > > > > > > Denis
> > > > > > > > > > >
> > > > > > > > > > > вт, 24 июл. 2018 г. в 12:44, Vyacheslav Daradur <
> > > > > [hidden email]
> > > > > > > > >:
> > > > > > > > > > >
> > > > > > > > > > > > No, it's doesn't complicate implementation on the
> > current
> > > > > stage.
> > > > > > > > > > > >
> > > > > > > > > > > > But we will have to change assignment function to
> > forbid
> > > > > client
> > > > > > > > nodes
> > > > > > > > > > > > even if configuration's node filter resolves them it
> > can
> > > be
> > > > > not
> > > > > > > > > > > > transparent for the end user.
> > > > > > > > > > > >
> > > > > > > > > > > > I think the only use case to have such behavior is:
> > > hosting
> > > > > of not
> > > > > > > > > > > > collocated services on data free nodes with access to
> > > > > IgniteCaches
> > > > > > > > on
> > > > > > > > > > > > remote nodes in the same cluster.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Jul 24, 2018 at 12:10 PM Denis Mekhanikov <
> > > > > > > > [hidden email]
> > > > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > I don't think, that client nodes, that host
> services
> > > make
> > > > > much
> > > > > > > > sense.
> > > > > > > > > > > > > May we forbid it? Does anybody know, when it may be
> > > useful?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Vyacheslav, does it complicate the implementation
> > > somehow?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Denis
> > > > > > > > > > > > >
> > > > > > > > > > > > > вт, 24 июл. 2018 г. в 11:57, Vyacheslav Daradur <
> > > > > > > > [hidden email]>:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi, Igniters!
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I am close to completing the main tasks and I'm
> > > going to
> > > > > > > > request a
> > > > > > > > > > > > > > review in a couple weeks.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I have a question about the new design:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The current implementation of Service Grid
> doesn't'
> > > take
> > > > > into
> > > > > > > > account
> > > > > > > > > > > > > > Ignition#client(true).
> > > > > > > > > > > > > > It means that *clients* nodes are able to host
> > > services.
> > > > > There
> > > > > > > > are
> > > > > > > > > > > > > > some tests that expect such behavior.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Services assignments are managed by a predicate
> > only
> > > > > > > > > > > > > >
> > (ServiceConfiguration#setNodeFilter(IgnitePredicate<
> > > > > > > > ClusterNode>).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Should deployment on clients nodes be forbidden
> or
> > we
> > > > > > > > shouldn't mix
> > > > > > > > > > > > > > concepts for IgniteCache with Service Grid?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Jun 20, 2018 at 1:46 AM Dmitriy
> Setrakyan <
> > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, Jun 19, 2018 at 1:50 PM, Vyacheslav
> > > Daradur <
> > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Dmitriy,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes, the task [1] is planned to be
> implemented
> > > once
> > > > > the
> > > > > > > > main
> > > > > > > > > > > tasks
> > > > > > > > > > > > > > > > will be completed.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > [1]
> > > > > https://issues.apache.org/jira/browse/IGNITE-8367
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Awesome! This is a huge addition to the
> project.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Jun 19, 2018 at 10:06 PM Dmitriy
> > > Setrakyan
> > > > > > > > > > > > > > > > <[hidden email]> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Vyacheslav,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > How about service redeployment in case if
> > user
> > > > > wants to
> > > > > > > > update
> > > > > > > > > > > > the
> > > > > > > > > > > > > > code?
> > > > > > > > > > > > > > > > Is
> > > > > > > > > > > > > > > > > this planned?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > D.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >
>

[dsetrakyan]

Anton, clients could be remote, not local. However, even if I agreed with
you, we cannot remove the current functionality from the product.

As suggested, by default services are deployed only on server nodes. If a
user wants to involve client nodes, then it should be done by specifying a
node filter. This is how the system works today. Let's not change it for no
good reason.

D.

On Fri, Jul 27, 2018 at 3:31 AM, Anton Vinogradov <[hidden email]> wrote:

> Denis,
>
> Main features of Ignite Cache are availability and throughput.
>
> I'd like to refactor Serviсe Grid to be the same.
> Main feature should be guarantee of availability and throughput (instance
> count).
>
> Client should ask grid to execute the service, that's all. No matter how
> grid will do this.
> This should be like cache 'put' or 'get' call.
>
> In case you want to execute something locally you should just implement it
> inside your application rather than deploy it to Ignite Cluster.
> There are absolutely no reason to mix local services and Service Grid.
>
> P.s. As for me, all "local" features should be deprecated, since we're
> distributed.
>
> чт, 26 июл. 2018 г. в 21:13, Denis Mekhanikov <[hidden email]>:
>
> > Anton,
> >
> > I believe, there are cases, when people want to have node singleton
> > services, that are deployed to clients, as well as to all other nodes.
> > And currently clients can execute compute jobs, issued by other clients,
> > and services are not very different from them.
> > Clients may store data and run code. We shouldn't consider them as
> > "end-user nodes". Only thin clients should be run by end users.
> >
> > But I agree, that we shouldn't encourage people to use services this way.
> > So, if it doesn't complicate the implementation too much, then a warning
> in
> > log will be enough, I think.
> >
> > Denis
> >
> > чт, 26 июл. 2018 г. в 19:56, Anton Vinogradov <[hidden email]>:
> >
> > > Folks,
> > >
> > > I don't think that it's a good idea to host services on client nodes.
> > > Client topology is not stable enough, and I don't see how to guarantee
> > > availability of such services.
> > > We'll have huge problems to guarantee availability in case of blinking
> > > clients.
> > >
> > > Also, taking into account that ignite cluster can have more that one
> user
> > > it looks odd that one user able to start service at another user's
> > hardware
> > > (bitcoin miners can be disagree with me).
> > >
> > > In case you want to use nodes only to host services - all you need is
> to
> > > filter them from cache affinity functions.
> > >
> > > I propose to implement Services pretty close to Cache implementation.
> > > It's a bad idea to reinvent the weel there.
> > > Let's just analyse Cache's code and do the same for services with same
> > > guarantee.
> > >
> > > ср, 25 июл. 2018 г. в 21:58, Vyacheslav Daradur <[hidden email]>:
> > >
> > > > Denis, long service initialization isn't a big problem for us.
> > > >
> > > > The problem is hung initialization, that means the service deployment
> > > > will never complete.
> > > > On Wed, Jul 25, 2018 at 8:08 PM Denis Mekhanikov <
> > [hidden email]>
> > > > wrote:
> > > > >
> > > > > Vyacheslav,
> > > > >
> > > > > I think, that this timeout shouldn't be mandatory, and it should be
> > > > > disabled by default.
> > > > > We should be ready for long service initialization. So, it
> shouldn't
> > be
> > > > > done in any crucial threads like discovery or exchange.
> > > > >
> > > > > Denis
> > > > >
> > > > > ср, 25 июл. 2018 г. в 15:59, Vyacheslav Daradur <
> [hidden email]
> > >:
> > > > >
> > > > > > FYI, I've filled the tickets:
> > > > > > https://issues.apache.org/jira/browse/IGNITE-9075
> > > > > > https://issues.apache.org/jira/browse/IGNITE-9076
> > > > > > On Wed, Jul 25, 2018 at 12:54 PM Vyacheslav Daradur <
> > > > [hidden email]>
> > > > > > wrote:
> > > > > > >
> > > > > > > > I think such timeout should be determined on per-service
> level.
> > > > Can we
> > > > > > make
> > > > > > > > it part of the service configuration, or pass it into deploy
> > > > method?
> > > > > > >
> > > > > > > Agree, per ServiceConfiguration level is more flexible
> solution.
> > > > > > >
> > > > > > > > This is a great question. Will the service be able to
> continue
> > > > > > operating
> > > > > > > > after the cache is destroyed? If not, I would undeploy it
> > > > > > automatically. If
> > > > > > > > yes, I would keep it. Please make sure that you are carefully
> > > > printing
> > > > > > out
> > > > > > > > informative logs in either case, to make sure that there is
> no
> > > > magic
> > > > > > > > happening that is hidden from users.
> > > > > > >
> > > > > > > A service will be able to work till topology's change after
> that
> > we
> > > > > > > have to recalculate assignments and at this moment we won't
> > > determine
> > > > > > > suitable nodes.
> > > > > > >
> > > > > > > I will fill new tickets to work on these questions and to
> > implement
> > > > > > > solutions in the second iteration if nobody doesn't mind.
> > > > > > > Anyway, it will have been done to a release.
> > > > > > > On Wed, Jul 25, 2018 at 12:08 PM Dmitriy Setrakyan
> > > > > > > <[hidden email]> wrote:
> > > > > > > >
> > > > > > > > On Tue, Jul 24, 2018 at 9:14 PM, Vyacheslav Daradur <
> > > > > > [hidden email]>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Igniters, please help me to clarify the following
> questions:
> > > > > > > > >
> > > > > > > > > 1). According to the issue [1] we should propagate services
> > > > > > deployment
> > > > > > > > > results to an initiator, that means we should wait for wor
> > > > > > > > > Service#init method completion.
> > > > > > > > > How should we handle Service#init method hangup?
> > > > > > > > > I propose to introduce some kind of
> > > > > > > > > IgniteSystemProperties#IGNITE_SERVICE_INIT_TIMEOUT to
> > interrupt
> > > > long
> > > > > > > > > initialization.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I think such timeout should be determined on per-service
> level.
> > > > Can we
> > > > > > make
> > > > > > > > it part of the service configuration, or pass it into deploy
> > > > method?
> > > > > > > >
> > > > > > > >
> > > > > > > > > 2) Should we automatically undeploy services, which had
> been
> > > > deployed
> > > > > > > > > using #deployKeyAffinitySingleton, on destroying of related
> > > > > > IgniteCache?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > This is a great question. Will the service be able to
> continue
> > > > > > operating
> > > > > > > > after the cache is destroyed? If not, I would undeploy it
> > > > > > automatically. If
> > > > > > > > yes, I would keep it. Please make sure that you are carefully
> > > > printing
> > > > > > out
> > > > > > > > informative logs in either case, to make sure that there is
> no
> > > > magic
> > > > > > > > happening that is hidden from users.
> > > > > > > >
> > > > > > > >
> > > > > > > > > Thoughts?
> > > > > > > > >
> > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-3392
> > > > > > > > > On Tue, Jul 24, 2018 at 3:01 PM Vyacheslav Daradur <
> > > > > > [hidden email]>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Got it.
> > > > > > > > > >
> > > > > > > > > > Yes, we will preserve this behavior.
> > > > > > > > > >
> > > > > > > > > > Thanks!
> > > > > > > > > > On Tue, Jul 24, 2018 at 2:20 PM Dmitriy Setrakyan <
> > > > > > [hidden email]>
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > By default the client nodes should be excluded form
> > service
> > > > > > > > > deployment. The
> > > > > > > > > > > only way to include clients is to explicitly specify
> them
> > > > > > through node
> > > > > > > > > > > filter. This is how services are deployed today and we
> > > should
> > > > > > preserve
> > > > > > > > > this
> > > > > > > > > > > behavior.
> > > > > > > > > > >
> > > > > > > > > > > D.
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Jul 24, 2018 at 11:20 AM, Denis Mekhanikov <
> > > > > > > > > [hidden email]>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Maybe let's keep the functionality the way it is,
> since
> > > it
> > > > > > doesn't
> > > > > > > > > > > > interfere with the IEP?
> > > > > > > > > > > >
> > > > > > > > > > > > But I think, it's worth mentioning as a warning in
> log,
> > > > that a
> > > > > > > > > service is
> > > > > > > > > > > > deployed on a client node.
> > > > > > > > > > > >
> > > > > > > > > > > > Denis
> > > > > > > > > > > >
> > > > > > > > > > > > вт, 24 июл. 2018 г. в 12:44, Vyacheslav Daradur <
> > > > > > [hidden email]
> > > > > > > > > >:
> > > > > > > > > > > >
> > > > > > > > > > > > > No, it's doesn't complicate implementation on the
> > > current
> > > > > > stage.
> > > > > > > > > > > > >
> > > > > > > > > > > > > But we will have to change assignment function to
> > > forbid
> > > > > > client
> > > > > > > > > nodes
> > > > > > > > > > > > > even if configuration's node filter resolves them
> it
> > > can
> > > > be
> > > > > > not
> > > > > > > > > > > > > transparent for the end user.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think the only use case to have such behavior is:
> > > > hosting
> > > > > > of not
> > > > > > > > > > > > > collocated services on data free nodes with access
> to
> > > > > > IgniteCaches
> > > > > > > > > on
> > > > > > > > > > > > > remote nodes in the same cluster.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Jul 24, 2018 at 12:10 PM Denis Mekhanikov <
> > > > > > > > > [hidden email]
> > > > > > > > > > > > >
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't think, that client nodes, that host
> > services
> > > > make
> > > > > > much
> > > > > > > > > sense.
> > > > > > > > > > > > > > May we forbid it? Does anybody know, when it may
> be
> > > > useful?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Vyacheslav, does it complicate the implementation
> > > > somehow?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > вт, 24 июл. 2018 г. в 11:57, Vyacheslav Daradur <
> > > > > > > > > [hidden email]>:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi, Igniters!
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I am close to completing the main tasks and I'm
> > > > going to
> > > > > > > > > request a
> > > > > > > > > > > > > > > review in a couple weeks.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I have a question about the new design:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The current implementation of Service Grid
> > doesn't'
> > > > take
> > > > > > into
> > > > > > > > > account
> > > > > > > > > > > > > > > Ignition#client(true).
> > > > > > > > > > > > > > > It means that *clients* nodes are able to host
> > > > services.
> > > > > > There
> > > > > > > > > are
> > > > > > > > > > > > > > > some tests that expect such behavior.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Services assignments are managed by a predicate
> > > only
> > > > > > > > > > > > > > >
> > > (ServiceConfiguration#setNodeFilter(IgnitePredicate<
> > > > > > > > > ClusterNode>).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Should deployment on clients nodes be forbidden
> > or
> > > we
> > > > > > > > > shouldn't mix
> > > > > > > > > > > > > > > concepts for IgniteCache with Service Grid?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Jun 20, 2018 at 1:46 AM Dmitriy
> > Setrakyan <
> > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Jun 19, 2018 at 1:50 PM, Vyacheslav
> > > > Daradur <
> > > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Dmitriy,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Yes, the task [1] is planned to be
> > implemented
> > > > once
> > > > > > the
> > > > > > > > > main
> > > > > > > > > > > > tasks
> > > > > > > > > > > > > > > > > will be completed.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > [1]
> > > > > > https://issues.apache.org/jira/browse/IGNITE-8367
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Awesome! This is a huge addition to the
> > project.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Tue, Jun 19, 2018 at 10:06 PM Dmitriy
> > > > Setrakyan
> > > > > > > > > > > > > > > > > <[hidden email]> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi Vyacheslav,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > How about service redeployment in case if
> > > user
> > > > > > wants to
> > > > > > > > > update
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > code?
> > > > > > > > > > > > > > > > > Is
> > > > > > > > > > > > > > > > > > this planned?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > D.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> > >
> >
>

[daradurvs]

Hi, Igniters!

I found a ticket about a service’s versioning [1].

It’s out of scope IEP-17, but if we are going to implement this
feature we should build a base in the first iteration of IEP-17
because of change messages formats.

In case of the versioning which assumes that we are able to host
services with the same name, but with different class/version, we
should introduce *service’s id* to manage service’s lifecycle instead
of service’s name.

Thoughts?


[1] https://issues.apache.org/jira/browse/IGNITE-6069
On Sat, Jul 28, 2018 at 3:51 AM Dmitriy Setrakyan <[hidden email]> wrote:

>
> Anton, clients could be remote, not local. However, even if I agreed with
> you, we cannot remove the current functionality from the product.
>
> As suggested, by default services are deployed only on server nodes. If a
> user wants to involve client nodes, then it should be done by specifying a
> node filter. This is how the system works today. Let's not change it for no
> good reason.
>
> D.
>
> On Fri, Jul 27, 2018 at 3:31 AM, Anton Vinogradov <[hidden email]> wrote:
>
> > Denis,
> >
> > Main features of Ignite Cache are availability and throughput.
> >
> > I'd like to refactor Serviсe Grid to be the same.
> > Main feature should be guarantee of availability and throughput (instance
> > count).
> >
> > Client should ask grid to execute the service, that's all. No matter how
> > grid will do this.
> > This should be like cache 'put' or 'get' call.
> >
> > In case you want to execute something locally you should just implement it
> > inside your application rather than deploy it to Ignite Cluster.
> > There are absolutely no reason to mix local services and Service Grid.
> >
> > P.s. As for me, all "local" features should be deprecated, since we're
> > distributed.
> >
> > чт, 26 июл. 2018 г. в 21:13, Denis Mekhanikov <[hidden email]>:
> >
> > > Anton,
> > >
> > > I believe, there are cases, when people want to have node singleton
> > > services, that are deployed to clients, as well as to all other nodes.
> > > And currently clients can execute compute jobs, issued by other clients,
> > > and services are not very different from them.
> > > Clients may store data and run code. We shouldn't consider them as
> > > "end-user nodes". Only thin clients should be run by end users.
> > >
> > > But I agree, that we shouldn't encourage people to use services this way.
> > > So, if it doesn't complicate the implementation too much, then a warning
> > in
> > > log will be enough, I think.
> > >
> > > Denis
> > >
> > > чт, 26 июл. 2018 г. в 19:56, Anton Vinogradov <[hidden email]>:
> > >
> > > > Folks,
> > > >
> > > > I don't think that it's a good idea to host services on client nodes.
> > > > Client topology is not stable enough, and I don't see how to guarantee
> > > > availability of such services.
> > > > We'll have huge problems to guarantee availability in case of blinking
> > > > clients.
> > > >
> > > > Also, taking into account that ignite cluster can have more that one
> > user
> > > > it looks odd that one user able to start service at another user's
> > > hardware
> > > > (bitcoin miners can be disagree with me).
> > > >
> > > > In case you want to use nodes only to host services - all you need is
> > to
> > > > filter them from cache affinity functions.
> > > >
> > > > I propose to implement Services pretty close to Cache implementation.
> > > > It's a bad idea to reinvent the weel there.
> > > > Let's just analyse Cache's code and do the same for services with same
> > > > guarantee.
> > > >
> > > > ср, 25 июл. 2018 г. в 21:58, Vyacheslav Daradur <[hidden email]>:
> > > >
> > > > > Denis, long service initialization isn't a big problem for us.
> > > > >
> > > > > The problem is hung initialization, that means the service deployment
> > > > > will never complete.
> > > > > On Wed, Jul 25, 2018 at 8:08 PM Denis Mekhanikov <
> > > [hidden email]>
> > > > > wrote:
> > > > > >
> > > > > > Vyacheslav,
> > > > > >
> > > > > > I think, that this timeout shouldn't be mandatory, and it should be
> > > > > > disabled by default.
> > > > > > We should be ready for long service initialization. So, it
> > shouldn't
> > > be
> > > > > > done in any crucial threads like discovery or exchange.
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > ср, 25 июл. 2018 г. в 15:59, Vyacheslav Daradur <
> > [hidden email]
> > > >:
> > > > > >
> > > > > > > FYI, I've filled the tickets:
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-9075
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-9076
> > > > > > > On Wed, Jul 25, 2018 at 12:54 PM Vyacheslav Daradur <
> > > > > [hidden email]>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I think such timeout should be determined on per-service
> > level.
> > > > > Can we
> > > > > > > make
> > > > > > > > > it part of the service configuration, or pass it into deploy
> > > > > method?
> > > > > > > >
> > > > > > > > Agree, per ServiceConfiguration level is more flexible
> > solution.
> > > > > > > >
> > > > > > > > > This is a great question. Will the service be able to
> > continue
> > > > > > > operating
> > > > > > > > > after the cache is destroyed? If not, I would undeploy it
> > > > > > > automatically. If
> > > > > > > > > yes, I would keep it. Please make sure that you are carefully
> > > > > printing
> > > > > > > out
> > > > > > > > > informative logs in either case, to make sure that there is
> > no
> > > > > magic
> > > > > > > > > happening that is hidden from users.
> > > > > > > >
> > > > > > > > A service will be able to work till topology's change after
> > that
> > > we
> > > > > > > > have to recalculate assignments and at this moment we won't
> > > > determine
> > > > > > > > suitable nodes.
> > > > > > > >
> > > > > > > > I will fill new tickets to work on these questions and to
> > > implement
> > > > > > > > solutions in the second iteration if nobody doesn't mind.
> > > > > > > > Anyway, it will have been done to a release.
> > > > > > > > On Wed, Jul 25, 2018 at 12:08 PM Dmitriy Setrakyan
> > > > > > > > <[hidden email]> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Jul 24, 2018 at 9:14 PM, Vyacheslav Daradur <
> > > > > > > [hidden email]>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Igniters, please help me to clarify the following
> > questions:
> > > > > > > > > >
> > > > > > > > > > 1). According to the issue [1] we should propagate services
> > > > > > > deployment
> > > > > > > > > > results to an initiator, that means we should wait for wor
> > > > > > > > > > Service#init method completion.
> > > > > > > > > > How should we handle Service#init method hangup?
> > > > > > > > > > I propose to introduce some kind of
> > > > > > > > > > IgniteSystemProperties#IGNITE_SERVICE_INIT_TIMEOUT to
> > > interrupt
> > > > > long
> > > > > > > > > > initialization.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I think such timeout should be determined on per-service
> > level.
> > > > > Can we
> > > > > > > make
> > > > > > > > > it part of the service configuration, or pass it into deploy
> > > > > method?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > 2) Should we automatically undeploy services, which had
> > been
> > > > > deployed
> > > > > > > > > > using #deployKeyAffinitySingleton, on destroying of related
> > > > > > > IgniteCache?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > This is a great question. Will the service be able to
> > continue
> > > > > > > operating
> > > > > > > > > after the cache is destroyed? If not, I would undeploy it
> > > > > > > automatically. If
> > > > > > > > > yes, I would keep it. Please make sure that you are carefully
> > > > > printing
> > > > > > > out
> > > > > > > > > informative logs in either case, to make sure that there is
> > no
> > > > > magic
> > > > > > > > > happening that is hidden from users.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > Thoughts?
> > > > > > > > > >
> > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-3392
> > > > > > > > > > On Tue, Jul 24, 2018 at 3:01 PM Vyacheslav Daradur <
> > > > > > > [hidden email]>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Got it.
> > > > > > > > > > >
> > > > > > > > > > > Yes, we will preserve this behavior.
> > > > > > > > > > >
> > > > > > > > > > > Thanks!
> > > > > > > > > > > On Tue, Jul 24, 2018 at 2:20 PM Dmitriy Setrakyan <
> > > > > > > [hidden email]>
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > By default the client nodes should be excluded form
> > > service
> > > > > > > > > > deployment. The
> > > > > > > > > > > > only way to include clients is to explicitly specify
> > them
> > > > > > > through node
> > > > > > > > > > > > filter. This is how services are deployed today and we
> > > > should
> > > > > > > preserve
> > > > > > > > > > this
> > > > > > > > > > > > behavior.
> > > > > > > > > > > >
> > > > > > > > > > > > D.
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Jul 24, 2018 at 11:20 AM, Denis Mekhanikov <
> > > > > > > > > > [hidden email]>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Maybe let's keep the functionality the way it is,
> > since
> > > > it
> > > > > > > doesn't
> > > > > > > > > > > > > interfere with the IEP?
> > > > > > > > > > > > >
> > > > > > > > > > > > > But I think, it's worth mentioning as a warning in
> > log,
> > > > > that a
> > > > > > > > > > service is
> > > > > > > > > > > > > deployed on a client node.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Denis
> > > > > > > > > > > > >
> > > > > > > > > > > > > вт, 24 июл. 2018 г. в 12:44, Vyacheslav Daradur <
> > > > > > > [hidden email]
> > > > > > > > > > >:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > No, it's doesn't complicate implementation on the
> > > > current
> > > > > > > stage.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > But we will have to change assignment function to
> > > > forbid
> > > > > > > client
> > > > > > > > > > nodes
> > > > > > > > > > > > > > even if configuration's node filter resolves them
> > it
> > > > can
> > > > > be
> > > > > > > not
> > > > > > > > > > > > > > transparent for the end user.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think the only use case to have such behavior is:
> > > > > hosting
> > > > > > > of not
> > > > > > > > > > > > > > collocated services on data free nodes with access
> > to
> > > > > > > IgniteCaches
> > > > > > > > > > on
> > > > > > > > > > > > > > remote nodes in the same cluster.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Jul 24, 2018 at 12:10 PM Denis Mekhanikov <
> > > > > > > > > > [hidden email]
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I don't think, that client nodes, that host
> > > services
> > > > > make
> > > > > > > much
> > > > > > > > > > sense.
> > > > > > > > > > > > > > > May we forbid it? Does anybody know, when it may
> > be
> > > > > useful?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Vyacheslav, does it complicate the implementation
> > > > > somehow?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > вт, 24 июл. 2018 г. в 11:57, Vyacheslav Daradur <
> > > > > > > > > > [hidden email]>:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi, Igniters!
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I am close to completing the main tasks and I'm
> > > > > going to
> > > > > > > > > > request a
> > > > > > > > > > > > > > > > review in a couple weeks.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I have a question about the new design:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The current implementation of Service Grid
> > > doesn't'
> > > > > take
> > > > > > > into
> > > > > > > > > > account
> > > > > > > > > > > > > > > > Ignition#client(true).
> > > > > > > > > > > > > > > > It means that *clients* nodes are able to host
> > > > > services.
> > > > > > > There
> > > > > > > > > > are
> > > > > > > > > > > > > > > > some tests that expect such behavior.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Services assignments are managed by a predicate
> > > > only
> > > > > > > > > > > > > > > >
> > > > (ServiceConfiguration#setNodeFilter(IgnitePredicate<
> > > > > > > > > > ClusterNode>).
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Should deployment on clients nodes be forbidden
> > > or
> > > > we
> > > > > > > > > > shouldn't mix
> > > > > > > > > > > > > > > > concepts for IgniteCache with Service Grid?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Jun 20, 2018 at 1:46 AM Dmitriy
> > > Setrakyan <
> > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Tue, Jun 19, 2018 at 1:50 PM, Vyacheslav
> > > > > Daradur <
> > > > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi Dmitriy,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Yes, the task [1] is planned to be
> > > implemented
> > > > > once
> > > > > > > the
> > > > > > > > > > main
> > > > > > > > > > > > > tasks
> > > > > > > > > > > > > > > > > > will be completed.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > [1]
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-8367
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Awesome! This is a huge addition to the
> > > project.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, Jun 19, 2018 at 10:06 PM Dmitriy
> > > > > Setrakyan
> > > > > > > > > > > > > > > > > > <[hidden email]> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi Vyacheslav,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > How about service redeployment in case if
> > > > user
> > > > > > > wants to
> > > > > > > > > > update
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > code?
> > > > > > > > > > > > > > > > > > Is
> > > > > > > > > > > > > > > > > > > this planned?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > D.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > > >
> > >
> >

--
Best Regards, Vyacheslav D.

[dsetrakyan]

On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <[hidden email]>
wrote:

> Hi, Igniters!
>
> I found a ticket about a service’s versioning [1].
>
> It’s out of scope IEP-17, but if we are going to implement this
> feature we should build a base in the first iteration of IEP-17
> because of change messages formats.
>
> In case of the versioning which assumes that we are able to host
> services with the same name, but with different class/version, we
> should introduce *service’s id* to manage service’s lifecycle instead
> of service’s name.
>
> Thoughts?
>

My only concern would be on the usability side. Is user going to have to
deal with IDs now, or will it be handled internally?

D.

[daradurvs]

We won't change API, user will continue to use service's name to manage it.

Some kind of service id will be used internally, this allow us to
distinguish services with the same name, but different version.


On Thu, Aug 9, 2018 at 4:32 PM Dmitriy Setrakyan <[hidden email]> wrote:

>
> On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <[hidden email]>
> wrote:
>
> > Hi, Igniters!
> >
> > I found a ticket about a service’s versioning [1].
> >
> > It’s out of scope IEP-17, but if we are going to implement this
> > feature we should build a base in the first iteration of IEP-17
> > because of change messages formats.
> >
> > In case of the versioning which assumes that we are able to host
> > services with the same name, but with different class/version, we
> > should introduce *service’s id* to manage service’s lifecycle instead
> > of service’s name.
> >
> > Thoughts?
> >
>
> My only concern would be on the usability side. Is user going to have to
> deal with IDs now, or will it be handled internally?
>
> D.

--
Best Regards, Vyacheslav D.

[Denis Mekhanikov]

I don't think, that we really need this feature.
It seems to me, that if you want to use a different implementation of a
service, you can assign a different name to it.

What do you think?

Denis

чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan <[hidden email]>:

> On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <[hidden email]>
> wrote:
>
> > Hi, Igniters!
> >
> > I found a ticket about a service’s versioning [1].
> >
> > It’s out of scope IEP-17, but if we are going to implement this
> > feature we should build a base in the first iteration of IEP-17
> > because of change messages formats.
> >
> > In case of the versioning which assumes that we are able to host
> > services with the same name, but with different class/version, we
> > should introduce *service’s id* to manage service’s lifecycle instead
> > of service’s name.
> >
> > Thoughts?
> >
>
> My only concern would be on the usability side. Is user going to have to
> deal with IDs now, or will it be handled internally?
>
> D.
>

[daradurvs]

Denis, it's not about different users services implementations.

A real use case is user's services API versioning which is being used
widely t in SOAP/REST microservices infrastructure.

In my opinion, it is about services with the same name and the same
full class name, but different classes versions for example in
different classloaders.


On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov <[hidden email]> wrote:

>
> I don't think, that we really need this feature.
> It seems to me, that if you want to use a different implementation of a
> service, you can assign a different name to it.
>
> What do you think?
>
> Denis
>
> чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan <[hidden email]>:
>
> > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <[hidden email]>
> > wrote:
> >
> > > Hi, Igniters!
> > >
> > > I found a ticket about a service’s versioning [1].
> > >
> > > It’s out of scope IEP-17, but if we are going to implement this
> > > feature we should build a base in the first iteration of IEP-17
> > > because of change messages formats.
> > >
> > > In case of the versioning which assumes that we are able to host
> > > services with the same name, but with different class/version, we
> > > should introduce *service’s id* to manage service’s lifecycle instead
> > > of service’s name.
> > >
> > > Thoughts?
> > >
> >
> > My only concern would be on the usability side. Is user going to have to
> > deal with IDs now, or will it be handled internally?
> >
> > D.
> >

--
Best Regards, Vyacheslav D.

[Denis Mekhanikov]

Vyacheslav,

It looks like an overcomplication to me.
Could you describe a case, that can be solved using versioning, but not
naming?

Denis

чт, 9 авг. 2018 г. в 16:56, Vyacheslav Daradur <[hidden email]>:

> Denis, it's not about different users services implementations.
>
> A real use case is user's services API versioning which is being used
> widely t in SOAP/REST microservices infrastructure.
>
> In my opinion, it is about services with the same name and the same
> full class name, but different classes versions for example in
> different classloaders.
>
>
> On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov <[hidden email]>
> wrote:
> >
> > I don't think, that we really need this feature.
> > It seems to me, that if you want to use a different implementation of a
> > service, you can assign a different name to it.
> >
> > What do you think?
> >
> > Denis
> >
> > чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan <[hidden email]>:
> >
> > > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <
> [hidden email]>
> > > wrote:
> > >
> > > > Hi, Igniters!
> > > >
> > > > I found a ticket about a service’s versioning [1].
> > > >
> > > > It’s out of scope IEP-17, but if we are going to implement this
> > > > feature we should build a base in the first iteration of IEP-17
> > > > because of change messages formats.
> > > >
> > > > In case of the versioning which assumes that we are able to host
> > > > services with the same name, but with different class/version, we
> > > > should introduce *service’s id* to manage service’s lifecycle instead
> > > > of service’s name.
> > > >
> > > > Thoughts?
> > > >
> > >
> > > My only concern would be on the usability side. Is user going to have
> to
> > > deal with IDs now, or will it be handled internally?
> > >
> > > D.
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

[dsetrakyan]

Guys,

I thought this was about automatic service redeployment, which should have
been a part of the current IEP, no? Can you please clarify?

D.

On Thu, Aug 9, 2018 at 9:26 AM, Denis Mekhanikov <[hidden email]>
wrote:

> Vyacheslav,
>
> It looks like an overcomplication to me.
> Could you describe a case, that can be solved using versioning, but not
> naming?
>
> Denis
>
> чт, 9 авг. 2018 г. в 16:56, Vyacheslav Daradur <[hidden email]>:
>
> > Denis, it's not about different users services implementations.
> >
> > A real use case is user's services API versioning which is being used
> > widely t in SOAP/REST microservices infrastructure.
> >
> > In my opinion, it is about services with the same name and the same
> > full class name, but different classes versions for example in
> > different classloaders.
> >
> >
> > On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov <[hidden email]>
> > wrote:
> > >
> > > I don't think, that we really need this feature.
> > > It seems to me, that if you want to use a different implementation of a
> > > service, you can assign a different name to it.
> > >
> > > What do you think?
> > >
> > > Denis
> > >
> > > чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan <[hidden email]>:
> > >
> > > > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <
> > [hidden email]>
> > > > wrote:
> > > >
> > > > > Hi, Igniters!
> > > > >
> > > > > I found a ticket about a service’s versioning [1].
> > > > >
> > > > > It’s out of scope IEP-17, but if we are going to implement this
> > > > > feature we should build a base in the first iteration of IEP-17
> > > > > because of change messages formats.
> > > > >
> > > > > In case of the versioning which assumes that we are able to host
> > > > > services with the same name, but with different class/version, we
> > > > > should introduce *service’s id* to manage service’s lifecycle
> instead
> > > > > of service’s name.
> > > > >
> > > > > Thoughts?
> > > > >
> > > >
> > > > My only concern would be on the usability side. Is user going to have
> > to
> > > > deal with IDs now, or will it be handled internally?
> > > >
> > > > D.
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

[daradurvs]

Dmitry, it's not only about hot redeployment.

Denis, I don't see such use case, because of the answer in a different front.

It relates to the best practices of SOA versioning [1] [2].

For example:
* we have a cluster with service [name="MySevice", v="1"];
* I want to upgrade service to [name="MySevice", v="2"], but I have
clients which are using [name="MySevice", v="1"] and can't stop
processing;
* With service versioning, we are able to deploy new service near
existing service, then switch clients and undeploy outdated service.

My only question is: are we going to implement such a feature [3] or
not? Maybe PMC don't see such feature in Service Grid roadmap.
IMO it's a good feature for a microservices platform.


[1] https://www.thbs.com/thbs-insights/soa-service-versioning-best-practices
[2] https://www.ibm.com/blogs/bluemix/2017/08/rapidly-developing-applications-part-6-exposing-and-versioning-apis/
[3] https://issues.apache.org/jira/browse/IGNITE-6069
On Thu, Aug 9, 2018 at 5:48 PM Dmitriy Setrakyan <[hidden email]> wrote:

>
> Guys,
>
> I thought this was about automatic service redeployment, which should have
> been a part of the current IEP, no? Can you please clarify?
>
> D.
>
> On Thu, Aug 9, 2018 at 9:26 AM, Denis Mekhanikov <[hidden email]>
> wrote:
>
> > Vyacheslav,
> >
> > It looks like an overcomplication to me.
> > Could you describe a case, that can be solved using versioning, but not
> > naming?
> >
> > Denis
> >
> > чт, 9 авг. 2018 г. в 16:56, Vyacheslav Daradur <[hidden email]>:
> >
> > > Denis, it's not about different users services implementations.
> > >
> > > A real use case is user's services API versioning which is being used
> > > widely t in SOAP/REST microservices infrastructure.
> > >
> > > In my opinion, it is about services with the same name and the same
> > > full class name, but different classes versions for example in
> > > different classloaders.
> > >
> > >
> > > On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov <[hidden email]>
> > > wrote:
> > > >
> > > > I don't think, that we really need this feature.
> > > > It seems to me, that if you want to use a different implementation of a
> > > > service, you can assign a different name to it.
> > > >
> > > > What do you think?
> > > >
> > > > Denis
> > > >
> > > > чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan <[hidden email]>:
> > > >
> > > > > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <
> > > [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > Hi, Igniters!
> > > > > >
> > > > > > I found a ticket about a service’s versioning [1].
> > > > > >
> > > > > > It’s out of scope IEP-17, but if we are going to implement this
> > > > > > feature we should build a base in the first iteration of IEP-17
> > > > > > because of change messages formats.
> > > > > >
> > > > > > In case of the versioning which assumes that we are able to host
> > > > > > services with the same name, but with different class/version, we
> > > > > > should introduce *service’s id* to manage service’s lifecycle
> > instead
> > > > > > of service’s name.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > >
> > > > > My only concern would be on the usability side. Is user going to have
> > > to
> > > > > deal with IDs now, or will it be handled internally?
> > > > >
> > > > > D.
> > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >

--
Best Regards, Vyacheslav D.

[dsetrakyan]

Vyacheslav,

For the case you are describing, I would take the same approach as we have
for compute tasks. Keep the older version around only as long as there are
active requests and then undeploy it automatically. No need to allow it
linger around indefinitely.

D.

On Thu, Aug 9, 2018 at 9:52 AM, Vyacheslav Daradur <[hidden email]>
wrote:

> Dmitry, it's not only about hot redeployment.
>
> Denis, I don't see such use case, because of the answer in a different
> front.
>
> It relates to the best practices of SOA versioning [1] [2].
>
> For example:
> * we have a cluster with service [name="MySevice", v="1"];
> * I want to upgrade service to [name="MySevice", v="2"], but I have
> clients which are using [name="MySevice", v="1"] and can't stop
> processing;
> * With service versioning, we are able to deploy new service near
> existing service, then switch clients and undeploy outdated service.
>
> My only question is: are we going to implement such a feature [3] or
> not? Maybe PMC don't see such feature in Service Grid roadmap.
> IMO it's a good feature for a microservices platform.
>
>
> [1] https://www.thbs.com/thbs-insights/soa-service-
> versioning-best-practices
> [2] https://www.ibm.com/blogs/bluemix/2017/08/rapidly-
> developing-applications-part-6-exposing-and-versioning-apis/
> [3] https://issues.apache.org/jira/browse/IGNITE-6069
> On Thu, Aug 9, 2018 at 5:48 PM Dmitriy Setrakyan <[hidden email]>
> wrote:
> >
> > Guys,
> >
> > I thought this was about automatic service redeployment, which should
> have
> > been a part of the current IEP, no? Can you please clarify?
> >
> > D.
> >
> > On Thu, Aug 9, 2018 at 9:26 AM, Denis Mekhanikov <[hidden email]>
> > wrote:
> >
> > > Vyacheslav,
> > >
> > > It looks like an overcomplication to me.
> > > Could you describe a case, that can be solved using versioning, but not
> > > naming?
> > >
> > > Denis
> > >
> > > чт, 9 авг. 2018 г. в 16:56, Vyacheslav Daradur <[hidden email]>:
> > >
> > > > Denis, it's not about different users services implementations.
> > > >
> > > > A real use case is user's services API versioning which is being used
> > > > widely t in SOAP/REST microservices infrastructure.
> > > >
> > > > In my opinion, it is about services with the same name and the same
> > > > full class name, but different classes versions for example in
> > > > different classloaders.
> > > >
> > > >
> > > > On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov <
> [hidden email]>
> > > > wrote:
> > > > >
> > > > > I don't think, that we really need this feature.
> > > > > It seems to me, that if you want to use a different implementation
> of a
> > > > > service, you can assign a different name to it.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Denis
> > > > >
> > > > > чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan <
> [hidden email]>:
> > > > >
> > > > > > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <
> > > > [hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi, Igniters!
> > > > > > >
> > > > > > > I found a ticket about a service’s versioning [1].
> > > > > > >
> > > > > > > It’s out of scope IEP-17, but if we are going to implement this
> > > > > > > feature we should build a base in the first iteration of IEP-17
> > > > > > > because of change messages formats.
> > > > > > >
> > > > > > > In case of the versioning which assumes that we are able to
> host
> > > > > > > services with the same name, but with different class/version,
> we
> > > > > > > should introduce *service’s id* to manage service’s lifecycle
> > > instead
> > > > > > > of service’s name.
> > > > > > >
> > > > > > > Thoughts?
> > > > > > >
> > > > > >
> > > > > > My only concern would be on the usability side. Is user going to
> have
> > > > to
> > > > > > deal with IDs now, or will it be handled internally?
> > > > > >
> > > > > > D.
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

[Anton Vinogradov-2]

Real case is A/B testing.
When you want to allow new service usage only to 0.1% of users.
And only when you sure it works then replace all v1 with v2.

So, I vote for versions.
Let's do this in maven way (exact version, range, RELEASE or LATEST)

чт, 9 авг. 2018 г. в 17:55, Dmitriy Setrakyan <[hidden email]>:

> Vyacheslav,
>
> For the case you are describing, I would take the same approach as we have
> for compute tasks. Keep the older version around only as long as there are
> active requests and then undeploy it automatically. No need to allow it
> linger around indefinitely.
>
> D.
>
> On Thu, Aug 9, 2018 at 9:52 AM, Vyacheslav Daradur <[hidden email]>
> wrote:
>
> > Dmitry, it's not only about hot redeployment.
> >
> > Denis, I don't see such use case, because of the answer in a different
> > front.
> >
> > It relates to the best practices of SOA versioning [1] [2].
> >
> > For example:
> > * we have a cluster with service [name="MySevice", v="1"];
> > * I want to upgrade service to [name="MySevice", v="2"], but I have
> > clients which are using [name="MySevice", v="1"] and can't stop
> > processing;
> > * With service versioning, we are able to deploy new service near
> > existing service, then switch clients and undeploy outdated service.
> >
> > My only question is: are we going to implement such a feature [3] or
> > not? Maybe PMC don't see such feature in Service Grid roadmap.
> > IMO it's a good feature for a microservices platform.
> >
> >
> > [1] https://www.thbs.com/thbs-insights/soa-service-
> > versioning-best-practices
> > [2] https://www.ibm.com/blogs/bluemix/2017/08/rapidly-
> > developing-applications-part-6-exposing-and-versioning-apis/
> > [3] https://issues.apache.org/jira/browse/IGNITE-6069
> > On Thu, Aug 9, 2018 at 5:48 PM Dmitriy Setrakyan <[hidden email]>
> > wrote:
> > >
> > > Guys,
> > >
> > > I thought this was about automatic service redeployment, which should
> > have
> > > been a part of the current IEP, no? Can you please clarify?
> > >
> > > D.
> > >
> > > On Thu, Aug 9, 2018 at 9:26 AM, Denis Mekhanikov <
> [hidden email]>
> > > wrote:
> > >
> > > > Vyacheslav,
> > > >
> > > > It looks like an overcomplication to me.
> > > > Could you describe a case, that can be solved using versioning, but
> not
> > > > naming?
> > > >
> > > > Denis
> > > >
> > > > чт, 9 авг. 2018 г. в 16:56, Vyacheslav Daradur <[hidden email]
> >:
> > > >
> > > > > Denis, it's not about different users services implementations.
> > > > >
> > > > > A real use case is user's services API versioning which is being
> used
> > > > > widely t in SOAP/REST microservices infrastructure.
> > > > >
> > > > > In my opinion, it is about services with the same name and the same
> > > > > full class name, but different classes versions for example in
> > > > > different classloaders.
> > > > >
> > > > >
> > > > > On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov <
> > [hidden email]>
> > > > > wrote:
> > > > > >
> > > > > > I don't think, that we really need this feature.
> > > > > > It seems to me, that if you want to use a different
> implementation
> > of a
> > > > > > service, you can assign a different name to it.
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan <
> > [hidden email]>:
> > > > > >
> > > > > > > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <
> > > > > [hidden email]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi, Igniters!
> > > > > > > >
> > > > > > > > I found a ticket about a service’s versioning [1].
> > > > > > > >
> > > > > > > > It’s out of scope IEP-17, but if we are going to implement
> this
> > > > > > > > feature we should build a base in the first iteration of
> IEP-17
> > > > > > > > because of change messages formats.
> > > > > > > >
> > > > > > > > In case of the versioning which assumes that we are able to
> > host
> > > > > > > > services with the same name, but with different
> class/version,
> > we
> > > > > > > > should introduce *service’s id* to manage service’s lifecycle
> > > > instead
> > > > > > > > of service’s name.
> > > > > > > >
> > > > > > > > Thoughts?
> > > > > > > >
> > > > > > >
> > > > > > > My only concern would be on the usability side. Is user going
> to
> > have
> > > > > to
> > > > > > > deal with IDs now, or will it be handled internally?
> > > > > > >
> > > > > > > D.
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

[dsetrakyan]

Versions will complicate the implementation and will not be done in 2.7. I
would vote for the hot redeployment for now and add versions in 2.8.

D.

On Thu, Aug 9, 2018 at 10:06 AM, Anton Vinogradov <[hidden email]> wrote:

> Real case is A/B testing.
> When you want to allow new service usage only to 0.1% of users.
> And only when you sure it works then replace all v1 with v2.
>
> So, I vote for versions.
> Let's do this in maven way (exact version, range, RELEASE or LATEST)
>
> чт, 9 авг. 2018 г. в 17:55, Dmitriy Setrakyan <[hidden email]>:
>
> > Vyacheslav,
> >
> > For the case you are describing, I would take the same approach as we
> have
> > for compute tasks. Keep the older version around only as long as there
> are
> > active requests and then undeploy it automatically. No need to allow it
> > linger around indefinitely.
> >
> > D.
> >
> > On Thu, Aug 9, 2018 at 9:52 AM, Vyacheslav Daradur <[hidden email]>
> > wrote:
> >
> > > Dmitry, it's not only about hot redeployment.
> > >
> > > Denis, I don't see such use case, because of the answer in a different
> > > front.
> > >
> > > It relates to the best practices of SOA versioning [1] [2].
> > >
> > > For example:
> > > * we have a cluster with service [name="MySevice", v="1"];
> > > * I want to upgrade service to [name="MySevice", v="2"], but I have
> > > clients which are using [name="MySevice", v="1"] and can't stop
> > > processing;
> > > * With service versioning, we are able to deploy new service near
> > > existing service, then switch clients and undeploy outdated service.
> > >
> > > My only question is: are we going to implement such a feature [3] or
> > > not? Maybe PMC don't see such feature in Service Grid roadmap.
> > > IMO it's a good feature for a microservices platform.
> > >
> > >
> > > [1] https://www.thbs.com/thbs-insights/soa-service-
> > > versioning-best-practices
> > > [2] https://www.ibm.com/blogs/bluemix/2017/08/rapidly-
> > > developing-applications-part-6-exposing-and-versioning-apis/
> > > [3] https://issues.apache.org/jira/browse/IGNITE-6069
> > > On Thu, Aug 9, 2018 at 5:48 PM Dmitriy Setrakyan <
> [hidden email]>
> > > wrote:
> > > >
> > > > Guys,
> > > >
> > > > I thought this was about automatic service redeployment, which should
> > > have
> > > > been a part of the current IEP, no? Can you please clarify?
> > > >
> > > > D.
> > > >
> > > > On Thu, Aug 9, 2018 at 9:26 AM, Denis Mekhanikov <
> > [hidden email]>
> > > > wrote:
> > > >
> > > > > Vyacheslav,
> > > > >
> > > > > It looks like an overcomplication to me.
> > > > > Could you describe a case, that can be solved using versioning, but
> > not
> > > > > naming?
> > > > >
> > > > > Denis
> > > > >
> > > > > чт, 9 авг. 2018 г. в 16:56, Vyacheslav Daradur <
> [hidden email]
> > >:
> > > > >
> > > > > > Denis, it's not about different users services implementations.
> > > > > >
> > > > > > A real use case is user's services API versioning which is being
> > used
> > > > > > widely t in SOAP/REST microservices infrastructure.
> > > > > >
> > > > > > In my opinion, it is about services with the same name and the
> same
> > > > > > full class name, but different classes versions for example in
> > > > > > different classloaders.
> > > > > >
> > > > > >
> > > > > > On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov <
> > > [hidden email]>
> > > > > > wrote:
> > > > > > >
> > > > > > > I don't think, that we really need this feature.
> > > > > > > It seems to me, that if you want to use a different
> > implementation
> > > of a
> > > > > > > service, you can assign a different name to it.
> > > > > > >
> > > > > > > What do you think?
> > > > > > >
> > > > > > > Denis
> > > > > > >
> > > > > > > чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan <
> > > [hidden email]>:
> > > > > > >
> > > > > > > > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <
> > > > > > [hidden email]>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi, Igniters!
> > > > > > > > >
> > > > > > > > > I found a ticket about a service’s versioning [1].
> > > > > > > > >
> > > > > > > > > It’s out of scope IEP-17, but if we are going to implement
> > this
> > > > > > > > > feature we should build a base in the first iteration of
> > IEP-17
> > > > > > > > > because of change messages formats.
> > > > > > > > >
> > > > > > > > > In case of the versioning which assumes that we are able to
> > > host
> > > > > > > > > services with the same name, but with different
> > class/version,
> > > we
> > > > > > > > > should introduce *service’s id* to manage service’s
> lifecycle
> > > > > instead
> > > > > > > > > of service’s name.
> > > > > > > > >
> > > > > > > > > Thoughts?
> > > > > > > > >
> > > > > > > >
> > > > > > > > My only concern would be on the usability side. Is user going
> > to
> > > have
> > > > > > to
> > > > > > > > deal with IDs now, or will it be handled internally?
> > > > > > > >
> > > > > > > > D.
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >
>