Bug 470576 - Migration could do addition checks before commiting actions
Summary: Migration could do addition checks before commiting actions
Alias: None
Product: Red Hat Directory Server
Classification: Red Hat
Component: Migration
Version: 8.0
Hardware: All
OS: Other
Target Milestone: ---
: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
Depends On:
Blocks: 639035 389_1.2.9
TreeView+ depends on / blocked
Reported: 2008-11-07 19:03 UTC by Bob Joslin
Modified: 2016-05-06 14:29 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-05-06 14:29:01 UTC

Attachments (Terms of Use)
0001-Bug-470576-ds.patch (2.74 KB, patch)
2010-10-23 01:58 UTC, Endi Sukma Dewata
no flags Details | Diff
0001-Bug-470576-admin.patch (11.57 KB, patch)
2010-10-23 01:59 UTC, Endi Sukma Dewata
no flags Details | Diff
Revised Patch (2.69 KB, patch)
2011-01-13 18:27 UTC, Nathan Kinder
no flags Details | Diff

Description Bob Joslin 2008-11-07 19:03:18 UTC
Description of problem:

During migration, there are a number of error conditions that will cause migration to fail.  Since migration attempts to perform its steps in an atomic-like operation, users must remove bogus instances and configuration in order to recover and attempt to re-migrate.  There are several steps that migration could perform before starting to create new server instances:

  - Handle SSL (migration will fail if SSL is on and no pin file exists or the certificate is expired)
  - Validate schema (server may fail to start up if new schema conflicts with already installed schema, such as the Samba password policy schema).
  - Verify that LDIF files of the data bases exists, if migration requires them.
  - Verify sufficient disk space to complete new instance import.

Comment 1 Nathan Kinder 2009-02-03 21:51:56 UTC
I think that the schema check may be difficult to do without creating the new instance first, but the rest of the requested checks should be implemented without too much difficulty.

For the schema validation, it's best to leverage the schema validation code that the ns-slapd program already does.  The best way of doing this is to create the new instance (with new default schema), then try to migrate in the schema from the old instance.  If we don't create a new instance first, we would need to have full schema parsing and validation logic in the migration code.

Comment 2 Nathan Kinder 2009-02-04 23:20:19 UTC
It turns out that most of these checks will require more work than anticipated.  The best approach would really be to make migration clean up after itself in the case of a failure.  This approach would not make us try to check difficult things such as the result of schema merging in the migration Perl code.

Pushing this to 8.2.

Comment 4 Endi Sukma Dewata 2010-10-23 01:58:46 UTC
Created attachment 455211 [details]

Comment 5 Endi Sukma Dewata 2010-10-23 01:59:11 UTC
Created attachment 455212 [details]

Comment 6 Nathan Kinder 2011-01-13 18:27:00 UTC
Created attachment 473385 [details]
Revised Patch

This simply removes an unnecessary for loop from the previous ds patch.

Comment 7 Nathan Kinder 2011-01-13 18:27:23 UTC
Pushed revised DS patch to master.

Counting objects: 13, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (7/7), 994 bytes, done.
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   3bcba24..8aee2bd  master -> master

Comment 8 Nathan Kinder 2011-01-13 19:03:36 UTC
Pushed admin patch to master.

Counting objects: 19, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (10/10), 1.93 KiB, done.
Total 10 (delta 8), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/admin.git
   3be5637..cbd46e4  master -> master

Note You need to log in before you can comment on or make changes to this bug.