ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: Service grid redesign
Date Wed, 11 Apr 2018 19:36:13 GMT
Denis,

I think that the service deployment state needs be persisted cluster-wide.
I guess that our meta-store is capable of doing so. Alex G., Vladimir,
could you confirm?

As for the split-brain scenarios, I would put them aside for now because,
anyway, they have to be solved at lower levels (meta store, discovery,
etc.).

Also, I heard that presently we store a service configuration in the system
cache that doesn't give us a way to deploy a new version of a service
without undeployment of the previous one. Will this issue be addressed by
the new deployment approach?

--
Denis

On Wed, Apr 11, 2018 at 1:28 AM, Denis Mekhanikov <dmekhanikov@gmail.com>
wrote:

> Denis,
>
> Sounds reasonable. It's not clear, though, what should happen, if a joining
> node has some services persisted, that are missing on other nodes.
> Should we deploy them?
> If we do so, it could lead to surprising behaviour. For example you could
> kill a node, undeploy a service, then bring back an old node, and it would
> make the service resurrect.
> We could store some deployment counter along with the service
> configurations on all nodes, that would show how many times the service
> state has changed, i.e. it has been undeployed/redeployed. It should be
> kept for undeployed services as well to avoid situations like I described.
>
> But it still leaves a possibility of incorrect behaviour, if there was a
> split-brain situation at some point. I don't think we should precess it
> somehow, though. If we choose to tackle it, it will overcomplicate things
> for a sake of a minor improvement.
>
> Denis
>
> вт, 10 апр. 2018 г. в 0:55, Valentin Kulichenko <
> valentin.kulichenko@gmail.com>:
>
> > I was responding to another Denis :) Agree with you on your point though.
> >
> > -Val
> >
> > On Mon, Apr 9, 2018 at 2:48 PM, Denis Magda <dmagda@apache.org> wrote:
> >
> > > Val,
> > >
> > > Guess we're talking about other situations. I'm bringing up the case
> > when a
> > > service was deployed dynamically and has to be brought up after a full
> > > cluster restart w/o user intervention. To achieve this we need to
> persist
> > > the service's configuration somewhere.
> > >
> > > --
> > > Denis
> > >
> > > On Mon, Apr 9, 2018 at 1:42 PM, Valentin Kulichenko <
> > > valentin.kulichenko@gmail.com> wrote:
> > >
> > > > Denis,
> > > >
> > > > EVT_CLASS_DEPLOYED should be fired every time a class is deployed or
> > > > redeployed. If this doesn't happen in some cases, I believe this
> would
> > > be a
> > > > bug. I don't think we need to add any new events.
> > > >
> > > > -Val
> > > >
> > > > On Mon, Apr 9, 2018 at 10:50 AM, Denis Magda <dmagda@apache.org>
> > wrote:
> > > >
> > > > > Denis,
> > > > >
> > > > > I would encourage us to persist a service configuration in the meta
> > > store
> > > > > and have this capability enabled by default. That's essential for
> > > > services
> > > > > started dynamically. Moreover, we support similar behavior for
> > caches,
> > > > > indexes, and other DDL changes happened at runtime.
> > > > >
> > > > > --
> > > > > Denis
> > > > >
> > > > > On Mon, Apr 9, 2018 at 9:34 AM, Denis Mekhanikov <
> > > dmekhanikov@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Another question, that I would like to discuss is whether
> services
> > > > should
> > > > > > be preserved on cluster restarts.
> > > > > >
> > > > > > Currently it depends on persistence configuration. If persistence
> > for
> > > > any
> > > > > > data region is enabled, then services will be persisted as well.
> > This
> > > > is
> > > > > a
> > > > > > pretty strange way of configuring this behaviour.
> > > > > > I'm not sure, if anybody relies on this functionality right
now.
> > > Should
> > > > > we
> > > > > > support it at all? If yes, should we make it configurable?
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > пн, 9 апр. 2018 г. в 19:27, Denis Mekhanikov <
> > dmekhanikov@gmail.com
> > > >:
> > > > > >
> > > > > > > Val,
> > > > > > >
> > > > > > > Sounds reasonable. I just think, that user should have
some way
> > to
> > > > > know,
> > > > > > > that new version of a service class was deployed.
> > > > > > > One way to do it is to listen to *EVT_CLASS_DEPLOYED. *I'm
not
> > > sure,
> > > > > > > whether it is triggered on class redeployment, though.
If not,
> > then
> > > > > > another
> > > > > > > event type should be added.
> > > > > > >
> > > > > > > I don't think, that a lot of people will implement their
own
> > > > > > > *DeploymentSpi*-s, so we should make work with
> *UriDeploymentSpi*
> > > as
> > > > > > > comfortable as possible.
> > > > > > >
> > > > > > > Denis
> > > > > > >
> > > > > > > пт, 6 апр. 2018 г. в 23:40, Valentin Kulichenko
<
> > > > > > > valentin.kulichenko@gmail.com>:
> > > > > > >
> > > > > > >> Yes, the class deployment itself has to be explicit.
I.e.,
> there
> > > has
> > > > > to
> > > > > > be
> > > > > > >> a manual step where user updates the class, and the
exact step
> > > > > required
> > > > > > >> would depend on DeploymentSpi implementation. But then
Ignite
> > > takes
> > > > > care
> > > > > > >> of
> > > > > > >> everything else - service redeployment and restart
is
> automatic.
> > > > > > >>
> > > > > > >> Dmitriy Pavlov, all this is going to be disabled if
> > DeploymentSpi
> > > is
> > > > > not
> > > > > > >> configured. In this case service class definitions
have to be
> > > > deployed
> > > > > > on
> > > > > > >> local classpath and can't be updated in runtime. Just
like it
> > > works
> > > > > > right
> > > > > > >> now.
> > > > > > >>
> > > > > > >> -Val
> > > > > > >>
> > > > > > >> On Fri, Apr 6, 2018 at 10:20 AM, Dmitriy Setrakyan
<
> > > > > > dsetrakyan@apache.org
> > > > > > >> >
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >> > On Fri, Apr 6, 2018 at 9:13 AM, Dmitry Pavlov
<
> > > > > dpavlov.spb@gmail.com>
> > > > > > >> > wrote:
> > > > > > >> >
> > > > > > >> > > Hi Igniters,
> > > > > > >> > >
> > > > > > >> > > I like automatic redeploy which can be disabled
by config
> if
> > > > user
> > > > > > >> wants
> > > > > > >> > to
> > > > > > >> > > control this process. What do you think?
> > > > > > >> > >
> > > > > > >> >
> > > > > > >> > I do not think we should have anything automatic
when it
> comes
> > > to
> > > > > > >> > deployment, everything should be explicit. However,
if we
> use
> > > the
> > > > > > >> > deployment SPI, then a user should be able to
do "hot"
> > redeploy,
> > > > > > where a
> > > > > > >> > new service will be deployed if the user drops
an updated
> jar.
> > > > > > >> >
> > > > > > >> > We should not create anything new here. Ignite
already has a
> > > > > > deployment
> > > > > > >> SPI
> > > > > > >> > and it already works in a certain way. Let's not
change it.
> > > > > > >> >
> > > > > > >> > D.
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message