On Wed, 2020-09-23 at 14:59 +0200, Massimo Sgaravatto wrote:
> From time to time (in particular where there are problems with the Rabbit
> cluster) I also see this problem. In such cases I "mark" the instance as
> deleted in the database. I don't know if there are cleaner solutions
>
> Cheers, Massimo
>
> [*]
> update instances set deleted=1 where uuid="<vm-uuid>";
this is not how you mark a vm as deleted.
you set deleted=id not 1

>
> On Tue, Sep 22, 2020 at 7:35 AM Szabo, Istvan (Agoda) <
> Istvan.Szabo@agoda.com> wrote:
>
> > The problem is that in opestack you can't find this vm if I want to delete:
> >
> >
> > nova reset-state 94ab55d3-3e39-48d3-a9b2-505838ceb6e7 --active
> > Reset state for server 94ab55d3-3e39-48d3-a9b2-505838ceb6e7 failed: No
> > server with a name or ID of '94ab55d3-3e39-48d3-a9b2-505838ceb6e7' exists.
> > ERROR (CommandError): Unable to reset the state for the specified
> > server(s).
> >
> >
> > openstack server delete 94ab55d3-3e39-48d3-a9b2-505838ceb6e7
> > No server with a name or ID of '94ab55d3-3e39-48d3-a9b2-505838ceb6e7'
> > exists.
> >
> >
> > nova force-delete 94ab55d3-3e39-48d3-a9b2-505838ceb6e7
> > ERROR (CommandError): No server with a name or ID of
> > '94ab55d3-3e39-48d3-a9b2-505838ceb6e7' exists.
> >
> >
> > openstack server delete hk-qaciapp-2020
> > No server with a name or ID of 'hk-qaciapp-2020' exists.
> >
> >
> > But if I list it like this can see:
> >
> > openstack server list --all-projects --long --limit -1 | grep
> > 94ab55d3-3e39-48d3-a9b2-505838ceb6e7
> > > 94ab55d3-3e39-48d3-a9b2-505838ceb6e7 | hk-qaciapp-2020
> >
> >       | BUILD   | scheduling | NOSTATE     |
> >        | CentOS-7-x86_64-1511 (14.11.2017)          |
> > 2caaef01-e2f9-4e93-961a-c2b2d4a6be82 | QA_VLAN62         | None            |
> >
> >
> > :/
> >
> >
> > It was created with the api before, maybe should try to delete with the
> > API? Not sure :/
> >
> > ________________________________
> > From: Ignazio Cassano <ignaziocassano@gmail.com>
> > Sent: Tuesday, September 22, 2020 12:21 PM
> > To: Szabo, Istvan (Agoda)
> > Cc: openstack-discuss
> > Subject: Re: Can't delete a vm
> >
> > Email received from outside the company. If in doubt don't click links nor
> > open attachments!
> > ________________________________
> > Hello, before feeling instance, try to use nova reset-state to change the
> > state of in instance to available.
> > Then try to remove.
> > Ignazio
> >
> > Il Mar 22 Set 2020, 06:43 Szabo, Istvan (Agoda) <Istvan.Szabo@agoda.com
> > <mailto:Istvan.Szabo@agoda.com>> ha scritto:
> > Hello,
> >
> >
> > I have vm which is stuck in the build phase:
> >
> >
> > openstack server list --all-projects --long --limit -1 | grep
> > 94ab55d3-3e39-48d3-a9b2-505838ceb6e7
> >                        | 94ab55d3-3e39-48d3-a9b2-505838ceb6e7 |
> > hk-qaciapp-2020                        | BUILD   | scheduling | NOSTATE
> >  |                                       | CentOS-7-x86_64-1511
> > (14.11.2017)          | 2caaef01-e2f9-4e93-961a-c2b2d4a6be82 | QA_VLAN62
> >      | None
> >
> >
> > I've tried to delete with openstack server delete, nova delete force,
> > restarted the nova services on all management nodes, restarted the nova
> > compute service where it was originally spawned but still visible.
> >
> >
> > I see in the database in couple of places either the id and either the
> > hostname, like in instance mapping table, instances table, nova_cell0
> > database ...
> >
> >
> > I have an idea how to delete, so I'd spawn just a vm and check which
> > tables are created the entries, and I would go through all tables with the
> > problematic one and delete 1 by 1 but this will takes me hours ....
> >
> > Any faster way you might suggest me please?
> >
> >
> > Thank you
> >
> >
> > ________________________________
> > This message is confidential and is for the sole use of the intended
> > recipient(s). It may also be privileged or otherwise protected by copyright
> > or other legal rules. If you have received it by mistake please let us know
> > by reply email and delete it from your system. It is prohibited to copy
> > this message or disclose its content to anyone. Any confidentiality or
> > privilege is not waived or lost by any mistaken delivery or unauthorized
> > disclosure of the message. All messages sent to and from Agoda may be
> > monitored to ensure compliance with company policies, to protect the
> > company's interests and to remove potential malware. Electronic messages
> > may be intercepted, amended, lost or deleted, or contain viruses.
> >
> >
> >