Launch_requests_blocking_on_approval

Launch requests blocking on approval

This scenario can be splitted into following steps:

• specify users who need approval for launching deployments and users who can approve these requests
• deliver/display approval requests
• launching of approved deployments

1. specify who needs approval and who can approve

We could use our current permissions model to define a set of users who needs approval. The set of these users would be defined on pool level by granting “create_with_approval”, instead of “create” action for Deployment object on a pool. So when creating and launching new deployment, we would check:

if check_privilege
 launch is done w/o approval
elsif check_privilege
 approval request is created
else
 raise permission error
end

To keep things simple, only users with MODIFY Deployment privilege on the pool could approve/reject approval requests.

2. approval requests delivery/presentation

It would be best to display pending approval requests in UI both to a user who requires deployment launch approve and to a user who can approve these request. New model for keeping pending requests will be required. This model will keep reference to deployment being launched, a user who wants launch this deployment and approvers. This record will be removed when approval is granted or rejected or when referenced deployment is deleted. After creating this request, mail notification about pending request is sent to approvers. This mail includes link to approve/reject form. In UI, list of pending requests could be displayed in the same way we display alerts both on “overview” page and on pool show page. Both request and approve form should have text field. The person doing the request could enter why they want this deployment. The pool owner could in turn specify the reason for rejection.

Update

Instead of using a model for keeping pending approval requests, new deployment state PENDING_APPROVAL could be used for deployments waiting for approve. The rest of workflow is unchanged. THe list of UI pending requests would then simply list, for users with the above-stated permissions, all Deployments in the PENDING_APPROVAL state. This would be preferred implementation way .

3. launching of approved deployments

Info about approving/rejecting a request would be logged as a new deployment event . Also mail notification is sent back to the user who sent the request. TODO: send this notification to other approvers too? If a deployment is approved, it’s queued for launch. In this case launch process consists of:

• checking permissions
• finding instance match - checking if instance match exists is done also before a user launches (=sends approval request) a deployment, if a match is not found at this point, only warning is displayed to the user (on deployment launch overview page) but he is still allowed to send launch approve request
• send instance launch requests

By default the deployment is launched immediately after approval, but once Scheduleddelayed_launch_and_maximum_execution_time is implemented, it should be compatible with it so a user can specify fixed time when the deployment should be launched and how long it should run. If the deployment is not approved/rejected by an approver before specified launch time occurs, then this deployment is automatically rejected and set to FAILED state. To make sure that auto-reject is done, some background job would be needed (can be queued at the moment when a user requires approval), alternatively could be done by some iterative checking on background.

If these steps fail, deployment state is set to ‘FAILED’. If a request is rejected, the deployment is not deleted, but its state is set to “FAILED” too. Reject is added to deployment events and probably to instance’s last_error so the user will be able to distinguish “admin disallowed” from “approved but no matches for launch” error.