-
Notifications
You must be signed in to change notification settings - Fork 27
Launch_requests_blocking_on_approval
Mo Morsi edited this page Jan 9, 2013
·
4 revisions
title: Launch_requests_blocking_on_approval
updated_on: Fri Jul 13 13:06:43 ~~0400 2012\
\
h1. 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
\
h2. 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:\
\<pre\>\
if check\_privilege\
launch is done w/o approval\
elsif check\_privilege\
approval request is created\
else\
raise permission error\
end\
\</pre\>
\
To keep things simple, only users with MODIFY Deployment privilege on
the pool could approve/reject approval requests.
\
h2. 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.
\
h3. 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 .
\
h2. 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.