ZAPI-685: deleteVm for a VM who doesn't exist on a server or whose server doesn't exist should not start a workflow

Resolution

Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2018-05-22T17:32:58.883Z)

Description

Currently, deleteVm starts a destroy workflow even if the VM to be deleted is on a server that doesn't exist, if the VM has an invalid server_uuid (e.g nul), or if the VM itself doesn't exist.

This destroy workflow depends on the VM existing on an actual server, so a workflow starting when these conditions are not met seems like a waste of time. The fact that each workflow and the current mechanism for VMAPI to poll their results are slow make things worse.

Checking these conditions from VMAPI directly before starting a destroy workflow seems like it would be both more correct and improve performance in these use cases.


Comments

Comment by Josh Wilsdon
Created at 2015-11-13T00:15:06.000Z
Updated at 2018-05-07T17:50:43.481Z
The only thing we need to watch out for here is when the VM is in the 'provisioning' state we don't want people to delete unless we've also actually cancelled any running provisions for it. As things are right now when we provision the initial placeholder records that we add (because its the workflow that adds the server_uuid) also don't have a server_uuid. However I think just rejecting DELETE actions when the VM is in state provisioning would be enough to prevent this.

Comment by Bot Bot [X]
Created at 2015-12-01T01:27:01.000Z

sdc-vmapi commit 5b1a3d4 (branch master, by Julien Gilli)

ZAPI-685: do not start a workflow on DELETE /vms if not needed

    When handling a DELETE /vms/some-vm request, do not start a workflow if
    one of the following conditions are true:

    1. The VM is in state 'provisioning'
    2. The VM doesn't have a server_uuid
    3. The server_uuid of the VM is not present in CNAPI

    In cases 2 and 3, mark the VM as destroyed and return a 200 HTTP status
    code. In case 1, return an error.

    Returning early and not starting a destroy workflow in these cases is
    faster and doesn't take any resource in the workflow's queue, thus
    allowing other workflows who have a chance to succeed to be processed
    more quickly.

    PR: #14
    PR-URL: https://github.com/joyent/sdc-vmapi/pull/14
    Reviewed-By: Josh Wilsdon <jwilsdon@joyent.com>
    Reviewed-By: Richard Kiene <richard.kiene@joyent.com>


Comment by Bot Bot [X]
Created at 2017-04-26T21:39:16.000Z

sdc-vmapi commit f820739 (branch master, by Julien Gilli)

ZAPI-782 ZAPI-685 broke DeleteVm
    Reviewed by: Trent Mick <trent.mick@joyent.com>
    Approved by: Trent Mick <trent.mick@joyent.com>


Comment by Angela Fong
Created at 2018-05-22T17:32:58.900Z
Looks like this has been fixed. We can reopen this or file a new ticket if the problem comes up again.