Re: Service grid redesign

controversial questions now. > > > > > > > > > > > > Thanks! > > > > > > > > > > > > [1] > > > http://apache-ignite-developers.2346864.n4.nabble.com/Danger-change-of-DiscoveryCustomEvent-in-GridDhtPartitionsExchangeFuture-onDone-td359

Re: Service grid redesign

e.com/Danger-change-of-DiscoveryCustomEvent-in-GridDhtPartitionsExchangeFuture-onDone-td35946.html > > > > > > > > > > > > > > > On Mon, Dec 24, 2018 at 4:23 PM Vyacheslav Daradur < > daradu...@gmail.com> wrote: > > > >

Re: Service grid redesign

; > > > > answered on GitHub. > > > > > > > > > > > > > > > On Sun, Dec 23, 2018 at 9:34 PM Stanislav Lukyanov > > > > > wrote: > > > > > > > > > > > > I’ve done a quick superficial review. D

Re: Service grid redesign

en resolved. I > > > > answered on GitHub. > > > > > > > > > > > > On Sun, Dec 23, 2018 at 9:34 PM Stanislav Lukyanov > > > > wrote: > > > > > > > > > > I’ve done a quick superficial review. Didn’t look at the

Re: Service grid redesign

I > > > answered on GitHub. > > > > > > > > > On Sun, Dec 23, 2018 at 9:34 PM Stanislav Lukyanov > > > wrote: > > > > > > > > I’ve done a quick superficial review. Didn’t look at the tests, didn’t > > > > dive into

Re: Service grid redesign

tanislav Lukyanov > > wrote: > > > > > > I’ve done a quick superficial review. Didn’t look at the tests, didn’t > > > dive into the design, etc, just the code. > > > I’ve left some comments – almost all are about minor issues, grammar and > > > co

Re: Service grid redesign

> > > > From: Vyacheslav Daradur > > Sent: 21 декабря 2018 г. 14:58 > > To: dev@ignite.apache.org > > Subject: Re: Service grid redesign > > > > Igniters, > > > > Please, let us know if someone is going to do an additional review? > > &

Re: Service grid redesign

ome comments – almost all are about minor issues, grammar and code > style. > > Stan > > From: Vyacheslav Daradur > Sent: 21 декабря 2018 г. 14:58 > To: dev@ignite.apache.org > Subject: Re: Service grid redesign > > Igniters, > > Please, let us know if someone is

RE: Service grid redesign

: Re: Service grid redesign Igniters, Please, let us know if someone is going to do an additional review? We should know can we merge the PR since it has been approved by Nikolay Izhikov and Denis Mekhanikov or we should wait for other community members. On Thu, Dec 20, 2018 at 7:52 PM Vyacheslav

Re: Service grid redesign

Igniters, Please, let us know if someone is going to do an additional review? We should know can we merge the PR since it has been approved by Nikolay Izhikov and Denis Mekhanikov or we should wait for other community members. On Thu, Dec 20, 2018 at 7:52 PM Vyacheslav Daradur wrote: > > I thin

Re: Service grid redesign

I think I found names which should satisfy me and Denis, and possibly Nikolay ) See the following names (Actual name <- Previously used): - ServiceDeploymentManager <- ServicesDeploymentManager - ServiceDeploymentActions <- ServicesDeploymentActions - ServiceDeploymentProcessId <- ServicesDeploym

Re: Service grid redesign

Denis, great news! Alexey, Vova, Yakov, do you want to take a look at this PR? В Ср, 19/12/2018 в 18:47 +0300, Denis Mekhanikov пишет: > Guys, > > I finished my code review. The pool request looks good to me. > > Does anybody else want to look at the changes? > There are a few points, that we

Re: Service grid redesign

Guys, I finished my code review. The pool request looks good to me. Does anybody else want to look at the changes? There are a few points, that we didn't meet an agreement on, though they don't affect the behaviour in any way: - *Class naming. * See the discussion above. - *Unnecessary tas

Re: Service grid redesign

Denis, I don't think that differences with your and my naming is huge :) And, it's definetely a matter of taste. If there is no any other issues with PR let's rename and move on! :) ср, 19 дек. 2018 г. в 17:32, Vyacheslav Daradur : > > We have IgniteServiceProcessor and GridServiceProcessor wit

Re: Service grid redesign

> We have IgniteServiceProcessor and GridServiceProcessor with singular > "Service" Maybe we should rename new 'IgniteServiceProcessor' to 'IgniteServicesProcessor'? > And ServiceSingleDeploymentsResults name doesn't make sense to me. > "Single deployments" doesn't sound right. 'Single' means '

Re: Service grid redesign

Slava, I think, it's better to replace word "Change" with "Request". Nik, We have IgniteServiceProcessor and GridServiceProcessor with singular "Service", ServicesDeploymentManager and ServicesDeploymentTask with plural "Services" for some reason. So, you need to remember, where Service and where

Re: Service grid redesign

>*1. Testing of the cache-based implementation of the service grid.* > I think, we should make a test suite, that will test the old implementation > until we remove it from the project. Agree. This is exactly what should be done as the first step once phase 1 will be merged. I think all tests in t

Re: Service grid redesign

Hello, Denis. Great news. > *1. Testing of the cache-based implementation of the service grid.* > I think, we should make a test suite, that will test the old implementation> > until we> remove it from the project. Aggree. Let's do it. > *2. DynamicServiceChangeRequest.* > I think, this class

Re: Service grid redesign

Guys, I've been looking through the PR by Vyacheslav for past few weeks. Slava, great job! You've done an impressive amount of work. I posted my comments to the PR and had a few calls with Slava. I am close to finishing my review. There are some points, that I'd like to settle in this discussion

Re: Service grid redesign

Alexey, I don't see any problem in letting services work on a deactivated cluster. All services need is discovery messages and compute tasks. Both of these features are available at all times. But it should be configurable. Services may need caches for their work, so it's better to undeploy such

Re: Service grid redesign

Hi, Vyacheslav! I'm thinking about to use Services API to implement Web Agent as a cluster singleton service. It will improve Web Console UX, because it will not needed to start separate java program. Just start cluster with Web agent enabled on cluster configuration. But in order to do this, I

Re: Service grid redesign

Hi, Igniters! I fixed the notes and tests seem good. So, let's continue the review [1] [2], any feedback is welcome! [1] https://github.com/apache/ignite/pull/4434 [2] https://issues.apache.org/jira/browse/IGNITE-9607 On Tue, Nov 27, 2018 at 5:16 PM Vyacheslav Daradur wrote: > > We had the priv

Re: Service grid redesign

We had the private talk with Nikolay Izhikov, Vladimir Ozerov, Alexey Goncharuk, Yakov Zhdanov, Denis Mekhanikov, Dmitriy Pavlov and I would like to share the summary with the community: The architecture of the implemented deployment process looks good in general, but the following points should b

Re: Service grid redesign

Hi Vyacheslav, Vladimir, Could you please invite me, if you will set up a call. ср, 21 нояб. 2018 г. в 13:08, Vladimir Ozerov : > Hi Vyacheslav, > > Still not clear enough for me. I do not see a reason to send another over a > ring in case of successful execution. The only reason is an error on

Re: Service grid redesign

Hi Vyacheslav, Still not clear enough for me. I do not see a reason to send another over a ring in case of successful execution. The only reason is an error on a node which require correction (re-deploy to other node, full service undeploy, etc). I think it makes sense to organize another call to

Re: Service grid redesign

The full map is needed: 1) to propagate deployment results which could be different from locally calculated in case of any errors; 2) to transfer deployment errors across the cluster; 3) to undeploy exceeded the number of service instances if needed; 4) to get know other nodes that deployment proce

Re: Service grid redesign

Vyacheslav, I looked at the document and failed to find explanation why full maps are needed. Could you point me to a place where it is explained? I ask this because my impression from last discussion was that it is never needed. Service status change is initiated by user action, then all nodes pe

Re: Service grid redesign

Denis, I suggested new names above in the thread. Please, look at PME document [1] is should be quiet actual to show the same flow. [1] https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood On Wed, Nov 21, 2018 at 11:43 AM Denis Mekhanikov wrote: > >

Re: Service grid redesign

During each deployment (exchange) process nodes send to the coordinator (p2p) deployments maps, caused: - users requests (deploy/undeploy) - affinity change (if affinity services present) - topology change (if services present) - activation (if services descriptors present) Also, single node deplo

Re: Service grid redesign

Vyacheslav, Actually, the service assignment is implemented in a way, that allows every node calculate the assignment itself, so no information needs to be shared. The only data, that is sent between nodes is deployment results, and I don't see an analogy with exchange here. Denis ср, 21 нояб. 2

Re: Service grid redesign

Hi Vyacheslav, Could you please explain in what situation coordinator needs to collect service deployments info from all nodes and share it with the cluster? I cannot remember from our design discussion when it is needed. Global state normally shared through discovery and only on node join, In thi

Re: Service grid redesign

Hello, Vladimir. > There is no "exchange", instead nodes send information to coordinator that they finished some operation 1. Each node sends to coordinator local deployments results. 2. Coordinator sends to each node full deployment map. This is the same process we have in PME for me. What have

Re: Service grid redesign

I think request-response is not suitable terms. Nodes send to coordinator maps of actual service deployments which contains what count of instances of each service node hosts locally. Coordinator sends to the cluster the full map of deployments across the cluster. On Wed, Nov 21, 2018 at 11:04 A

Re: Service grid redesign

I do not know what is correct term :-) What I said is that "exchange" is counter intuitive here. There is no "exchange", instead nodes send information to coordinator that they finished some operation. E.g. we do the same for schema changes (index creation), and as Denis suggested, Request-Response

Re: Service grid redesign

First, we must agree on names. I think the valuable word is 'deployment', though 'exchange' may be used too because there is an exchange of deployments maps during the deployment process. To avoid intersections with PME I suggest using the following names: ServicesFullMapMessage -> ServicesFullD

Re: Service grid redesign

Hello, Vladimir. What is correct term? ср, 21 нояб. 2018 г., 10:29 Vladimir Ozerov voze...@gridgain.com: > Agree. Service deployment has nothing to do with PME. We should not use the > same term for different things. > > вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov : > > > Vyacheslav, > > > >

Re: Service grid redesign

Agree. Service deployment has nothing to do with PME. We should not use the same term for different things. вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov : > Vyacheslav, > > I'm in process of reviewing your changes. Sorry for taking so long. > I posted the first portion of review comments yester

Re: Service grid redesign

Denis, thanks for your participation! >> There is no exchange in case of service deployment There is some kind of exchange of services map which describes mapping services instances to nodes in the cluster. I'm a bit confused because of your notes about naming, the main goal was to do the code to

Re: Service grid redesign

Vyacheslav, I'm in process of reviewing your changes. Sorry for taking so long. I posted the first portion of review comments yesterday. I'd like to finish looking through the code. I'll post more comments later. I see, that you called things analogously to partition map exchange. I realize, that

Re: Service grid redesign

Denis, Yakov have you had a chance to review the solution? Igniters, we need to define a list of reviewers, otherwise no end in sign. I'm ready to continue work on the Service Grid, including new features like hot-redeployment and versioning, also, I have ideas about new tools for monitoring and

Re: Service grid redesign

Denis, Yakov, feel free to contact me directly in case of questions. Thanks! On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov wrote: > > Guys, > > I'd like to take a look at the changes before they are merged. > I'll do my best to finish the review before the end of the upcoming week. > > Thanks

Re: Service grid redesign

Guys, I'd like to take a look at the changes before they are merged. I'll do my best to finish the review before the end of the upcoming week. Thanks! Denis сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov : > Hello, Vladimir. > > I'm agree with you. > > Can we write the list of reviewers for this

Re: Service grid redesign

Hello, Vladimir. I'm agree with you. Can we write the list of reviewers for this feature? Without a date or similar. Just a list of experts who should review this feature. В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет: > Igniters, > > This is very huge thing with complex algorithms beh

Re: Service grid redesign

Igniters, This is very huge thing with complex algorithms behind. We should not merge it to the product unless several additional thorough reviews are ready, irrespectively of how long will it take. We are about quality, not speed. сб, 10 нояб. 2018 г. в 1:30, Denis Magda : > Vyacheslav, > > Wha

Re: Service grid redesign

Vyacheslav, What are the cases when the service can be redeployed? Affinity, failure, etc., right. It would be good to list all the cases on the wiki and then our tech writers will get everything documented. -- Denis On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur wrote: > Denis, > > Servic

Re: Service grid redesign

Denis, Services reassignment process takes into account previous assignments to avoid redundant redeployments. So, in the described case, ServiceA won't be moved from node1 to node2. On Fri, Nov 9, 2018 at 4:41 AM Denis Magda wrote: > > Vyacheslav, > > First of all, thanks for archiving this mile

Re: Service grid redesign

Vyacheslav, First of all, thanks for archiving this milestone and rolling out these new capabilities. Speaking of the topology change events [1], does the new architecture avoid a running service redeployment when a new node joins? For instance, let's say I have ServiceA running node1, then node2

Re: Service grid redesign

Nikolay, let me take a look at the changes. I will do it possibly over weekend. Thanks! --Yakov 2018-11-08 17:20 GMT+03:00 Nikolay Izhikov : > Hello, Igniters. > > Please, respond if anyone wish to do the additional review of this > improvement. > > I think it's ready to be merged, so if noone

Re: Service grid redesign

Hello, Igniters. Please, respond if anyone wish to do the additional review of this improvement. I think it's ready to be merged, so if noone has time to review, I can merge the patch. ср, 7 нояб. 2018 г., 18:04 Vyacheslav Daradur daradu...@gmail.com: > Dmitriy, I published documentation in wik

Re: Service grid redesign

Dmitriy, I published documentation in wiki: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584 Thank you! On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov wrote: > > Hi I think wiki is better than any attached docs. Could you please create a > page? > > ср, 7 нояб. 2018 г., 14

Re: Service grid redesign

Hi I think wiki is better than any attached docs. Could you please create a page? ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur : > I prepared a description of the implemented solution and attached it > to the issue [1]. > > This should help during a review. Should I post the document into wiki o

Re: Service grid redesign

I prepared a description of the implemented solution and attached it to the issue [1]. This should help during a review. Should I post the document into wiki or IEP? I'd like to ask Ignite's experts review the solution [1] [2], please? [1] https://issues.apache.org/jira/browse/IGNITE-9607 [2] ht

Re: Service grid redesign

Hi, Igniters! Good news! Service Grid Redesign Phase 1 - is in Patch Available now. Nikolay Izhikov has reviewed implementation. However, we need additional review from other Ignite experts. Here is an umbrella ticket [1] and PR [2]. Could someone step in and do the review? [1] https://issues

Re: Service grid redesign

Pavel, could you assist? Does it make sense for .Net to specify service class name instead of its implementation? I think, it shouldn't be a problem. Denis On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur wrote: > I think that the replacement of serialized instance makes sense to me > for Java

Re: Service grid redesign

I think that the replacement of serialized instance makes sense to me for Java part. But how it should work for .NET client? On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan wrote: > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev > wrote: > > > Hello, Igniters. > > > > I am working on task

Re: Service grid redesign

On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev wrote: > Hello, Igniters. > > I am working on task [1] that would replace serialized service's instance > by service's class name and properties map in {ServiceConfiguration}. > > The task describes that we should use > {String className} + {Map pr

Re: Service grid redesign

Hello, Igniters. I am working on task [1] that would replace serialized service's instance by service's class name and properties map in {ServiceConfiguration}. The task describes that we should use {String className} + {Map properties} instead {Service srvc}. I'd like to clarify the following q

Re: Service grid redesign

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 wrote: > Real case is A/B testing. > When you want to allow new service usage only to 0.1% of user

Re: Service grid redesign

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 : > V

Re: Service grid redesign

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,

Re: Service grid redesign

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="My

Re: Service grid redesign

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 wrote: > Vyacheslav, > > It looks like an overcomplication to me. > Could you describe a case, that c

Re: Service grid redesign

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 : > Denis, it's not about different users services implementations. > > A real use case is user's services AP

Re: Service grid redesign

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 vers

Re: Service grid redesign

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 : > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur

Re: Service grid redesign

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 wrote: > > On Thu, Aug 9, 2018 at 4:41 A

Re: Service grid redesign

On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur 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 forma

Re: Service grid redesign

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 se

Re: Service grid redesign

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 filt

Re: Service grid redesign

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. Th

Re: Service grid redesign

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 c

Re: Service grid redesign

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

Re: Service grid redesign

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 wrote: > > Vyacheslav, > > I think, that this timeout shouldn't be mandatory, and it should be

Re: Service grid redesign

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 : > FYI, I'v

Re: Service grid redesign

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 wrote: > > > I think such timeout should be determined on per-service level. Can we make > > it part of the service

Re: Service grid redesign

> 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

Re: Service grid redesign

On Tue, Jul 24, 2018 at 9:14 PM, Vyacheslav Daradur 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

Re: Service grid redesign

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 som

Re: Service grid redesign

Got it. Yes, we will preserve this behavior. Thanks! On Tue, Jul 24, 2018 at 2:20 PM Dmitriy Setrakyan 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 ar

Re: Service grid redesign

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 wrote: >

Re: Service grid redesign

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 : > No, it's doesn't complicate implementation on

Re: Service grid redesign

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 c

Re: Service grid redesign

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 : > Hi, Igniters! > > I am close to completing the m

Re: Service grid redesign

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.

Re: Service grid redesign

On Tue, Jun 19, 2018 at 1:50 PM, Vyacheslav Daradur 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,

Re: Service grid redesign

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 On Tue, Jun 19, 2018 at 10:06 PM Dmitriy Setrakyan wrote: > > Hi Vyacheslav, > > How about service redeployment in case if user wants to update

Re: Service grid redesign

Hi Vyacheslav, How about service redeployment in case if user wants to update the code? Is this planned? D. On Tue, Jun 19, 2018 at 12:10 AM, Vyacheslav Daradur wrote: > Hi Denis! > > >> If to assume that Ignite 2.7 gets released in September, what else > would you be able to complete by that

Re: Service grid redesign

Hi Denis! >> If to assume that Ignite 2.7 gets released in September, what else would you >> be able to complete by that time? The following tasks will be completed by September: https://issues.apache.org/jira/browse/IGNITE-8361 - Use discovery messages for service deployment https://issues.apac

Re: Service grid redesign

Hi Vyacheslav, If to assume that Ignite 2.7 gets released in September, what else would you be able to complete by that time? I would see how to promote this from the community side (articles, webinars, meetups). Plus, do you think you'll be able to complete the whole IEP by the end of the year?

Re: Service grid redesign

Hi Igniters, sorry for the delay in replying. I going to finish the task [1] to the end of this month. [1] https://issues.apache.org/jira/browse/IGNITE-8361 On Wed, May 16, 2018 at 10:57 PM, Vyacheslav Daradur wrote: > Hi, Igniters! > > I had a discussion about the scope of work of IEP-17 with

Re: Service grid redesign

Hi, Igniters! I had a discussion about the scope of work of IEP-17 with Denis and Pavel. To estimate the time I took 2 weeks for R&D during which I would do the task: https://issues.apache.org/jira/browse/IGNITE-8361 Then I will inform the community about the planned work time. On Tue, May 8,

Re: Service grid redesign

Thanks, Denis! I assigned the task to myself. I going to start work next week. On Tue, May 8, 2018 at 7:50 PM, Denis Mekhanikov wrote: > Hi Vyacheslav! > > Thanks for the enthusiasm! > The first ticket to be implemented here is IGNITE-8361 > . >

Re: Service grid redesign

Hi Vyacheslav! Thanks for the enthusiasm! The first ticket to be implemented here is IGNITE-8361 . I think, until this one is resolved, other tasks can't be started. Please assign it to yourself, if you feel confident enough. Feel free to ask for

Re: Service grid redesign

Hi, Denis M., I'd like to pick up a ticket from IEP-17 next week. Could you please advise a ticket to start? On Tue, Apr 24, 2018 at 11:47 AM, Dmitriy Setrakyan wrote: > On Tue, Apr 24, 2018, 3:59 PM Denis Mekhanikov > wrote: > >> Dmitriy, >> >> After the proposed changes are made the utility

Re: Service grid redesign

On Tue, Apr 24, 2018, 3:59 PM Denis Mekhanikov wrote: > Dmitriy, > > After the proposed changes are made the utility cache won't be needed at > all. > I was rather talking about prioritization. In my view, first and foremost we must fix deployment before anything else. D.

Re: Service grid redesign

Dmitriy, After the proposed changes are made the utility cache won't be needed at all. I created the tickets for this IEP, you can find them on it's page: https://cwiki.apache.org/confluence/display/IGNITE/IEP-17%3A+Oil+Change+in+Service+Grid Or by label iep-17. The one for getting rid of the ut

Re: Service grid redesign

Thanks! The IEP looks very big. I would like to remind everyone that one of the biggest problems we have with services is that it uses a replicated cache internally to do the deployment. When all nodes have the same service configured in the XML file, then all nodes will try to initiate a put into

Re: Service grid redesign

Dmitriy, Consider IEP page as a summary that was updated along the way: https://cwiki.apache.org/confluence/display/IGNITE/IEP-17%3A+Oil+Change+in+Service+Grid As far as I understand, Denis is going to create JIRA tickets basing on the discussion results. -- Denis On Sat, Apr 21, 2018 at 3:04 A

Re: Service grid redesign

I am not sure why we are discussing a potential removal of the "init" method. I think it is useful, as the service may have to do some initialization before it goes online. I do not think this method is hurting anyone. This thread is getting too long, and I am sure that most readers are already ge

Re: Service grid redesign

Denis, > On the other hand, if exception is thrown from the *execute() *method, then service won't be undeployed. This is actually weird... What is going to happen in this case and how user would handle this? -Val On Fri, Apr 20, 2018 at 1:10 AM, Denis Mekhanikov wrote: > Val, > > *init()* me

  1   2   >