https://bugzilla.redhat.com/show_bug.cgi?id=480869
Resolves: bug 480869
Bug Description: DS console: Can not delete DS instance
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: As it turns out, my assumption that ds_remove in CGI
mode also did the unregistration was false. It is the console that does
the unregistration, only after the ds_remove CGI returns success. So,
ds_remove needs to run with AdminSDK off, just like the other "special"
CGI programs. In addition, ds_remove needs to be more robust - if there
is an error during ds_remove, you should be allowed to try again after
fixing something. However, the way the error handling worked did not
differentiate between fatal errors and errors that could be ignored. In
order to do this properly, we need to propagate the errors back up to
the top level (oh how I wish perl had real exception handling . . .).
The main type of error we need to ignore is file not found or process
not found. If we attempted to remove before and that attempt failed for
some reason, and left a partial instance, we need to be able to run the
remove command again, skipping over the things we shutdown or removed
already, and clean up the stuff we need to remove. This can also happen
if you use the console to create a ds instance, and remove-ds.pl to
remove the instance. The instance will still show up in the console.
We need to be able to use the Remove Server in the console to remove the
instance from the console, even through there is no physical instance on
disk any more. Since the console will only do the unregistration if the
CGI returns success, we need to make sure the CGI returns success even
though there is no instance on disk. When ds_remove is run via
ds_removal, it will do the unregistration.
I also took this opportunity to refactor the remove code, creating a
removeDSInstance method in DSCreate.pm, and moving some of the other
removal helper functions to Util.pm. That simplified the code in both
ds_remove and remove-ds.pl.
I added a remove-ds-admin.pl script - one of the problems that users
have is that they run setup-ds-admin.pl, then hit some error (e.g. bad
DNS setup), then find that they cannot restore the system to the state
before they ran setup-ds-admin.pl. remove-ds-admin.pl does this.
Finally, I added some man pages to the admin package for those commonly
used commands.
Platforms tested: RHEL4
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=333382&action=diff
https://bugzilla.redhat.com/attachment.cgi?id=333383&action=diff
--
Fedora-directory-devel mailing list
Fedora-directory-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-devel
