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 <dmekhani...@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.kuliche...@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 <dma...@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.kuliche...@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 <dma...@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 < > > > dmekhani...@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 < > > dmekhani...@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.kuliche...@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 < > > > > > > dsetrak...@apache.org > > > > > > >> > > > > > > > >> wrote: > > > > > > >> > > > > > > >> > On Fri, Apr 6, 2018 at 9:13 AM, Dmitry Pavlov < > > > > > dpavlov....@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. > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
