ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Mekhanikov <dmekhani...@gmail.com>
Subject Re: Service grid redesign
Date Wed, 11 Apr 2018 08:52:56 GMT
Guys,

I'm also thinking, at which moment services should be deployed on the
joining nodes.
It would be good to have all services deployed by the moment, when a node
is accepted to the topology.
I think, it should work like this:

   1. connecting node sends a *TcpDiscoveryJoinRequestMessage *with
   persisted services configurations attached to it;
   2. coordinator recalculates service assignments and attaches them to the
   successive *TcpDiscoveryNodeAddedMessage*;
   3. connecting node receives the assignments, initialises all needed
   services and sends confirmation to the coordinator on completion;
   4. coordinator sends *TcpDiscoveryNodeAddFinishedMessage* only when it
   receives confirmation about deployed services from the joining node.

What do you think? Any pitfalls? Some discovery expert should look at this
procedure and tell, if it is viable.

Denis

ср, 11 апр. 2018 г. в 11:28, Denis Mekhanikov <dmekhanikov@gmail.com>:

> 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