+1
On Wed, Sep 6, 2017 at 8:54 PM, Dmitriy Setrakyan
wrote:
> I would agree on removing the partial deployment flag, but I do not like
> the all-or-nothing approach. I would still vote for the partial deployment
> support. Users should get an exception with services that failed and
> potentially
I would agree on removing the partial deployment flag, but I do not like
the all-or-nothing approach. I would still vote for the partial deployment
support. Users should get an exception with services that failed and
potentially retry them on their own.
Let's keep the partial deployment semantic o
Guys,
If service deployment *can* be easily rolled back - then we do not need the
flag and should have strict semantics "all-or-nothing". Users do not need
partial semantics. This is not ATOMIC cache, this is services.
If service deployment *cannot* be rolled back - then we do not need the
flag e
> If we cannot rollback services, then what is the use of "boolean
allOrNone"?
Currently services deployment may fail only on configuration check or on
write to the internal cache. Both of these operations are performed before
any services are deployed, so rollback means just transaction rollback.
Dima,
I agree with your reasoning. My outstanding question is why we have a flag?
If we cannot rollback services, then what is the use of "boolean
allOrNone"? Let's just remove it and always deploy services partially,
throwing Exception with proper infromation about failed services.
On Wed, Sep 6
On Wed, Sep 6, 2017 at 8:24 AM, Pavel Tupitsyn wrote:
> Agree with Vova, partial deployment does not make much sense in deployAll
> method.
> Partial deployment can be performed with a deploy method in a loop.
>
That's exactly what we are trying to fix - deploy in a loop is slow and
sequential.
Agree with Vova, partial deployment does not make much sense in deployAll
method.
Partial deployment can be performed with a deploy method in a loop.
On Wed, Sep 6, 2017 at 6:21 PM, Vladimir Ozerov
wrote:
> Well, if we cannot rollback services easily then *why* we have a mode where
> we declare
Well, if we cannot rollback services easily then when we have a mode where
we declare a kind of false "atomicity"?
On Wed, Sep 6, 2017 at 6:17 PM, Dmitriy Setrakyan
wrote:
> On Wed, Sep 6, 2017 at 8:10 AM, Vladimir Ozerov
> wrote:
>
> > Dima,
> >
> > No, my point is to remove method with flag a
Well, if we cannot rollback services easily then *why* we have a mode where
we declare a kind of false "atomicity"?
On Wed, Sep 6, 2017 at 6:21 PM, Vladimir Ozerov
wrote:
> Well, if we cannot rollback services easily then when we have a mode where
> we declare a kind of false "atomicity"?
>
> On
On Wed, Sep 6, 2017 at 8:10 AM, Vladimir Ozerov
wrote:
> Dima,
>
> No, my point is to remove method with flag and never allow partial
> deployment. I do not needsee any practical use cases for this.
>
The problem is not in practical use cases, but also in our ability to
rollback the already star
Dima,
No, my point is to remove method with flag and never allow partial
deployment. I do not needsee any practical use cases for this.
On Wed, Sep 6, 2017 at 6:06 PM, Dmitriy Setrakyan
wrote:
> Vova, makes sense. Couple of comments.
>
>
>1. allowPartialUpdate -> allowPartialDeploy
>2.
Vova, makes sense. Couple of comments.
1. allowPartialUpdate -> allowPartialDeploy
2. I do not think we need the 2nd deployAll method. This is not the API
where we need convenience shortcuts.
3. Partial deployment is a failure, not success, so the exception should
be thrown. Howeve
Igniters,
Personally, I do not like the flag name - hard to understand and use. What
if instead we define the following API:
void deployAll(Collection cfgs, boolean
allowPartialUpdate) throws ServiceDeploymentException
void deployAll(Collection cfgs)
throws ServiceDeploymentException
The second
Sounds good! Thanks for the detailed info. Can you please provide the
updated API in the ticket?
On Thu, Aug 17, 2017 at 12:41 AM, Denis Mekhanikov
wrote:
> > Can we add an "allOrNone" flag to the deployment method?
>
> Sounds good, I think we can.
>
> > However, hot do you ensure atomicity here
> Can we add an "allOrNone" flag to the deployment method?
Sounds good, I think we can.
> However, hot do you ensure atomicity here?
We can guarantee that if some of configurations are invalid, or a
transaction, that writes configuration to the internal cache, fails, then
no services will be dep
On Wed, Aug 16, 2017 at 8:17 AM, Denis Mekhanikov
wrote:
> I've had a few off-line conversations with other Igniters regarding this
> question and almost all of them think that services should be deployed with
> "all-or-none" failing policy.
> We have a similar functionality for caches: Ignite#cr
I've had a few off-line conversations with other Igniters regarding this
question and almost all of them think that services should be deployed with
"all-or-none" failing policy.
We have a similar functionality for caches: Ignite#createCaches method
don't allow partial deployments, and I think, we
Denis,
I don't think we need a king deployment result.
The "deployAllAsync" method should never throw an exception, it should
always return the future. However, the IgniteFuture.get(...) method does
throw an exception, and in this exception you should provide the info about
the failures.
D.
On
Dmitriy, thank you for your reply!
I see a possibility of a bad scenario here. If we use deployAllAsync method
and it throws an exception, then the constructed future won't be returned
and we won't have a way to wait for the rest of the services to deploy.
Maybe we should return some king of deplo
Hi Denis, I agree, we should have an API for batch service deployment. My
comments are inline...
On Mon, Aug 14, 2017 at 2:22 AM, Denis Mekhanikov
wrote:
> Hi Igniters!
>
> Currently Ignite doesn't have support for batch service deployment, but it
> may be a very useful feature in case of a big
20 matches
Mail list logo
