ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vyacheslav Daradur <daradu...@gmail.com>
Subject Re: Service grid redesign
Date Wed, 25 Jul 2018 09:54:38 GMT
> 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
<dsetrakyan@apache.org> wrote:
>
> On Tue, Jul 24, 2018 at 9:14 PM, Vyacheslav Daradur <daradurvs@gmail.com>
> 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 <daradurvs@gmail.com>
> > wrote:
> > >
> > > Got it.
> > >
> > > Yes, we will preserve this behavior.
> > >
> > > Thanks!
> > > On Tue, Jul 24, 2018 at 2:20 PM Dmitriy Setrakyan <dsetrakyan@apache.org>
> > 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 <
> > dmekhanikov@gmail.com>
> > > > 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 <daradurvs@gmail.com
> > >:
> > > > >
> > > > > > 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 <
> > dmekhanikov@gmail.com
> > > > > >
> > > > > > 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
<
> > daradurvs@gmail.com>:
> > > > > > >
> > > > > > > > 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
<
> > > > > > dsetrakyan@apache.org>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Jun 19, 2018 at 1:50 PM, Vyacheslav Daradur
<
> > > > > > daradurvs@gmail.com
> > > > > > > > >
> > > > > > > > > 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
> > > > > > > > > > <dsetrakyan@apache.org> 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.

Mime
View raw message