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?
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.
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.
attachment 0001-Ticket-47878-Improve-setup-ds-update-logging.patch
d35239c..ac43090 master -> master commit ac43090 Author: Mark Reynolds mreynolds@redhat.com Date: Fri Jun 19 16:22:46 2015 -0400
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1240406
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1240407
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1240409
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
remove warning suppression in 1.3.4 0001-Ticket-47878-Remove-warning-suppression-in-1.3.4.patch
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
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.