Re: [Users] Is there a way to force remove a host?

From: "Itamar Heim" <iheim(a)redhat.com&gt; To: "Eli Mesika" <emesika(a)redhat.com&gt; Cc: dougsland(a)redhat.com, users(a)ovirt.org Sent: Sunday, September 23, 2012 3:07:03 PM Subject: Re: [Users] Is there a way to force remove a host? On 09/22/2012 11:19 PM, Eli Mesika wrote: > > > ----- Original Message ----- >> From: "Douglas Landgraf" <dougsland(a)redhat.com&gt; >> To: "Dominic Kaiser" <dominic(a)bostonvineyard.org&gt; >> Cc: "Eli Mesika" <emesika(a)redhat.com&gt;, users(a)ovirt.org, "Robert >> Middleswarth" <robert(a)middleswarth.net&gt; >> Sent: Friday, September 21, 2012 8:12:27 PM >> Subject: Re: [Users] Is there a way to force remove a host? >> >> Hi Dominic, >> >> On 09/20/2012 12:11 PM, Dominic Kaiser wrote: >>> Sorry I did not explain. >>> >>> I had tried to remove the host and had not luck troubleshooting >>> it. >>> I >>> then had removed it and used it for a storage unit reinstalling >>> fedora >>> 17. I foolishly thought that I could just remove the host >>> manually. >>> It physically is not there. (My fault I know) Is there a way >>> that >>> you know of to remove a host brute force. >>> >>> dk >> >> Fell free to try the below script (not part of official project) >> for >> brute force: >> >> (from the engine side) >> # yum install python-psycopg2 -y >> # wget >> https://raw.github.com/dougsland/misc-rhev/master/engine_force_remove_Hos... >> # (edit the file and change the db password) >> # python ./engine_force_remove_Host.py > > Hi , had looked in the Python script you had provided: > First, I must say that handling the database directly may leave DB > in inconsistent state, therefore, if there is no other option, the > database should be backed up prior to this operation. > In addition, I do not like the execution of the SQL statements in > the script. > There is a SP called DeleteVds(v_vds_id UUID) and you should use > that since it encapsulates all details. > For example, your script does not handle permission clean-up as the > SP does and therefore leaves garbage in the database. shouldn't foreign keys protect against this? (if not cascade deletes which i remember caused some issues with locks)

> In addition, a failure in your script may leave database in > inconsistent state while the SP is executed in one transaction and > will leave DB consistent. > So, in short I would prefer in this case that the relevant SP will > do the clean-up since this is the one that is used by the code and > that insures (at least I hope so) , that all related entities are > removed as well. > > >> >> Thanks >> >> -- >> Cheers >> Douglas >> >> > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >