pubapi-1370-potential-solutions.md

Introduction

PUBAPI-1370 describes the problem when a volume is being created and the provisioning of its storage VM fails:

• after the provisioning workflow started
• before the actual VM was created on the CN

In this case, the volume being created will stay in the state creating, since the volapi-updater process, which subscribes to VMAPI's changefeed publisher, won't receive any event related to any storage VM associated to that volume, since it hasn't and will not be created.

The same problem occurs for volume deletion, but this document focuses on presenting the problem with volume creation.

There are several ways to solve this problem, all with their pros and cons. They are described briefly in the rest of this document.

Add create-volume workflow in sdc-workflow from VOLAPI

• this workflow would contain only two tasks:

  1. sending a CreateVm request
  2. polling that task until the VM has started being provisioned on the CN

• If any of these tasks fail, the workflow posts an update to VOLAPI with a volume state of 'failed'

• Otherwise, it does nothing, the volume's state will be updated by the 'volapi-updater' process

pros

• handles VOLAPI crashes: there's no use case where a volume's state would stay 'creating' if VOLAPI crashes

• handles wf-runner (or any other workflow related crashes): at worst, a job that would provision a storage VM would be cancelled, and the associated volume state would be updated to 'failed'

cons

• introduces new workflows

poll the job's state from the CreateVolume endpoint's implementation

When the storage VM is created, a separate asynchronous process (e.g a function sheduled with setTimeout or setInterval) is started that polls the resulting provisioning job's uuid. This process updates the volume state to 'failed' if the job fails before the VM is actually provisioned on the CN.

pros

• Simple to implement: no need to add workflows from VOLAPI

cons

• A crash in VOLAPI when a VM provisioning workflow is in progress and will fail before a VM is being provisioned on a CN means that the volume will stay in a state 'creating'

Store vm-creation workflows uuid and poll from separate process

When the storage VM is provisioned, the provisioning job's uuid is stored in moray in a separate bucket, and a separate process polls that job. If the job fails before the VM is actually provisioned on a CN, it updates the volume's state to 'failed'.

pros

• does not necessitate the introduction of new workflows

cons

• complex to implement