Dmitriy,
Yes, as you can see in the first message in this thread, request
*DynamicServicesChangeRequestBatchMessage* is a container which is
able to transfer several actions for batch operations like
deployAll/cancelAll.
Also, it will be possible to combine operations for *deploy* and
*undeploy*
I also hope that we have some batching API to allow deployment of multiple
services together, either on grid startup or during the call to "deploy..."
API.
D.
On Thu, Aug 30, 2018 at 5:04 AM, Vyacheslav Daradur
wrote:
> Hi Igniters!
>
> I had a private talk about new Service Grid design with: A
Hi Igniters!
I had a private talk about new Service Grid design with: Alexey
Goncharuk, Vladimir Ozerov, Denis Mekhanikov, Nikolay Izhikov, Anton
Vinogradov and I'd like to share results.
Design looks good in general, but we have decided to improve the
unified flow of requests processing as follo
Agree with Val. I think all users would expect that a service is restarted
upon a node or cluster restart. Let's make sure we preserve this behavior.
D.
On Fri, Aug 24, 2018 at 4:17 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Guys,
>
> I believe we should preserve the behav
Guys,
I believe we should preserve the behavior that we have now. What happens to
services if we restart a persistent cluster running 2.6? Are services
recreated or not? If YES, we should make sure the same happens after
redesign. Would be even better if we preserve compatibility, i.e. allow
seaml
Denis M. & Val please share your vision about this topic.
пт, 24 авг. 2018 г. в 15:52, Vyacheslav Daradur :
> Nick, Antron, thank you for stepping in.
>
> AFAIK, Ignite cluster can move its state to a new version of Ignite
> using persistence only.
>
> Since Ignite v.2.3 persistence is configured
Nick, Antron, thank you for stepping in.
AFAIK, Ignite cluster can move its state to a new version of Ignite
using persistence only.
Since Ignite v.2.3 persistence is configured on a memory region and
system memory region is not persistence, that means the system
(utility) cache will not be recov
Vyacheslav.
It looks like we able to restart all services on grid startup from old
definitions (inside cache) in case persistence turned on.
Se no problems to provide such automated migration case.
Also, we can test it using compatibility framework.
BTW, Is proposed solution provides the guarante
Hello, Vyacheslav.
Thanks, for sharing your design.
> I have a question about services migration from AI 2.6 to a new solution
Can you describe consequences of not having migration solution?
What will happen on the user side?
В Чт, 23/08/2018 в 14:44 +0300, Vyacheslav Daradur пишет:
> Hi, Igni
Hi, Igniters!
I’m working on Service Grid redesign tasks and design seems to be finished.
The main goal of Service Grid redesign is to provide missed guarantees:
- Synchronous services deployment/undeployment;
- Failover on coordinator change;
- Propagation of deployments errors across the cluste
10 matches
Mail list logo
