On 09/25/2012 12:03 AM, Jason Brooks wrote:

On Mon 24 Sep 2012 02:55:54 PM PDT, Itamar Heim wrote:

On 09/24/2012 11:53 PM, Jason Brooks wrote:

On Mon 24 Sep 2012 01:24:44 PM PDT, Itamar Heim wrote:

On 09/24/2012 08:49 PM, Dominic Kaiser wrote:

This conversation is fine but if I want to force remove no matter
what I
should be able to from the GUI.  The nodes are no longer available I
want to get rid of them ovirt does not let me.  I can delete from
database but why not from the GUI?  I am sure others may run into this
problem as well.

what happens to the status of the host when you right click on the
host and specify you confirm it was shutdown?

I'm having this same issue. Confirming the host is shut down doesn't
make a difference.

I'm seeing lots of "Failed to GlusterHostRemoveVDS, error = Unexpected
exception" errors in my engine log that seem to correspond w/ the failed
remove host attempts.

is cluster defined as gluster as well?

Yes, it is.

that's a very important piece of information...
is there a more detailed exception in the log on the error?
can you uncheck gluster and try to remove it again?

Dominic - are you also using a cluster with gluster service enabled?

what is the status of the host after you confirm shutdown?
any error on log on this specific command?

I have two hosts I want to remove -- one, a failed add that never
completed, and the other, an F17 machine that I subsequently updated to
F18. So neither of those hosts are actually connected to my engine.
Their status is either non-responsive or maintenance, if I activate,
it's the former, if I set it to maintenance, it's the latter. I can only
attempt to remove in maintenance mode, so that's where I have them.

There don't appear to be any errors confirming manual reboot.

shireesh - not sure if relevant to this flow, but need to make sure
removing a host from the engine isn't blocked on gluster needing to
remove it from the gluster cluster if the host is not available any
more, or last host in gluster cluster?

Dominic

On Sep 22, 2012 4:19 PM, "Eli Mesika" <emesika@redhat.com
<mailto:emesika@redhat.com>> wrote:



    ----- Original Message -----
     > From: "Douglas Landgraf" <dougsland@redhat.com
    <mailto:dougsland@redhat.com>>
     > To: "Dominic Kaiser" <dominic@bostonvineyard.org
    <mailto:dominic@bostonvineyard.org>>
     > Cc: "Eli Mesika" <emesika@redhat.com
    <mailto:emesika@redhat.com>>, users@ovirt.org
    <mailto:users@ovirt.org>, "Robert Middleswarth"
    <robert@middleswarth.net <mailto:robert@middleswarth.net>>
     > 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_Host.py




     > # (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.
    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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

--

@jasonbrooks

--

@jasonbrooks