#47878 setup -u stops after first failure
Closed: wontfix None Opened 9 years ago by lkrispen.

If setup-ds.pl -u is run to upgrade several instances it stops after the first failure to upgarde an instance. It should report an error, but continue to upgrade the other instances.

In addition we should verify in which state the failing instance is after aborting an upgrade. Is it reset to the previous state ?


Sounds like a good idea.
When do we need this fix?

Setting target milestone to 1.3.4.
If IPA needs it earlier, please feel free to update it.

deferred cloning (not sure if we'll get to this)

Is there any kind of test case for this? How can I trigger a upgrade to fail on a partiuclar instance?

If setup-ds.pl -u is run to upgrade several instances it stops after the first failure to upgarde an instance. It should report an error, but continue to upgrade the other instances.

I think there should be an option to continue or stop at the first failure, and the default behavior should be to stop at the first failure.

In addition we should verify in which state the failing instance is after aborting an upgrade. Is it reset to the previous state ?

No, it is not reset, it is left in its (possibly) broken state. setup-ds.pl -u is supposed to be idempotent - you just keep running it until everything is updated - you can run it multiple times even after a successful update and it should not do anything.

We would need implement some sort of transaction/commit/rollback functionality in order to reset to the previous state.

Replying to [comment:6 mreynolds]:

Is there any kind of test case for this?

I don't know, but we'll need one.

How can I trigger a upgrade to fail on a partiuclar instance?

I suppose you could introduce some sort of syntax error in dse.ldif, or remove a file/directory, or ....

Replying to [comment:8 rmeggins]:

Replying to [comment:6 mreynolds]:

Is there any kind of test case for this?

I don't know, but we'll need one.

+1

How can I trigger a upgrade to fail on a partiuclar instance?

I suppose you could introduce some sort of syntax error in dse.ldif, or remove a file/directory, or ....

Of course I could hack a failure, but I was hoping for a real world testcase. This ticket was filed because there is a problem, and I just want to know how to trigger it. Ludwig, can you elaborate on this?

So for now I'll just hack a failure until a better testcase is available.

I'm not sure this ticket is necessary. You can specify the "continue/force" option and the update script will continue to process the remaining instances.

setup-ds.pl -h:

--continue (update only) keep going despite errors (also --force)

However, the logging will say that the update failed, even though some instances were successfully updated. I will work on improving the logging to clarify what instances were updated, and the ones that were not.

d35239c..ac43090 master -> master
commit ac43090
Author: Mark Reynolds mreynolds@redhat.com
Date: Fri Jun 19 16:22:46 2015 -0400

Reopened. RHEL 7 doesn't support the warning suppression in perl. Perl 5.18 supports this, but perl 5.16 does not. Need to backout change in 1.3.4

eeddc9f..d8b7a3c 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
commit d8b7a3c
Author: Mark Reynolds mreynolds@redhat.com
Date: Mon Jul 13 13:12:12 2015 -0400

Metadata Update from @nhosoi:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.4 backlog

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1209

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata