Bug 470576

Summary:

Migration could do addition checks before commiting actions

Product:

Red Hat Directory Server

Reporter:

Bob Joslin <bob_joslin>

Component:

Migration

Assignee:

Nathan Kinder <nkinder>

Status:

CLOSED CURRENTRELEASE

QA Contact:

Viktor Ashirov <vashirov>

Severity:

medium

Docs Contact:

Priority:

medium

Version:

8.0

CC:

amsharma, jgalipea, rmeggins, ulf.weltman

Target Milestone:

---

Keywords:

VerifiedUpstream

Target Release:

---

Hardware:

All

OS:

Other

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2016-05-06 14:29:01 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Bug Depends On:

Bug Blocks:

639035, 708096

Attachments:

Description	Flags
0001-Bug-470576-ds.patch	none
0001-Bug-470576-admin.patch	none
Revised Patch	none

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]
0001-Bug-470576-ds.patch

Comment 5 Endi Sukma Dewata 2010-10-23 01:59:11 UTC

Created attachment 455212 [details]
0001-Bug-470576-admin.patch

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