RFC: Launch requests blocking on approval (#3402)

Scott Seago sseago at redhat.com
Thu Jul 5 14:27:19 UTC 2012


On 07/04/2012 07:25 AM, Jan Provaznik wrote:
> Hi,
> draft is on wiki:
> https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Launch_requests_blocking_on_approval 
>
>
> It's just a kick off of discussion about this topic. I tried to keep 
> things simple in the draft for the beginning.
>
> Suggestions and comments are welcome.
>
> Jan
Here are a few comments
> require_privilege(Privilege::CREATE, Deployment, @pool)
> if check_privilege(Privilege::USE, Deployment, @pool)
>    launch is done w/o approval
> else
>    approval request is created
> end
>
> To keep things simple, only owner of the pool where a deployment is 
> being launched would be allowed to approve/reject these requests.
>
>
I think you've got the right idea here, but the details need some 
tweaking. USE Deployment privileges on the pool would give the user the 
rights to start/stop _any_ instances in the pool, not just the ones they 
launched, so I think that's too much of a big hammer here. We could 
create a new privilege action -- a lesser version of create, but we'd 
have to think carefully about other sorts of privilege action extensions 
we'd want in the future -- to attempt this in a consistent way. The 
difficulty is that the "privilege actions" are deliberately general so 
as to only need the same four across object types (create, modify, view, 
use). The other difficulty is that privileges at the pool level inherit 
to all deployments in the pool -- this is to allow pool 
owners/administrators the ability to administer all deployments in the 
pool across users. The only Deployment privilege non-admin users get for 
Deployments at the pool level is Create -- since that's needed to create 
Deployments in the first place. Perhaps we just add 
Privilege::CREATE_WITH_APPROVAL as a new action type.

Also, when yo usay the 'owner' of the pool would be allowed to 
approve/reject these requests, we will need to be explicit as to _which_ 
privilege we're checking. For example, we could say that any user with 
MODIFY Deployment privileges on the pool would be allowed to approve the 
request, since that user is allowed to modify any deployment in the pool 
anyway.

> 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.
>
So this would include any users with MODIFY Deployment privileges on the 
Pool, including those that get this privilege via the PoolFamily or via 
global permissions (Global Pool Admin or Administrator)
>
> 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 an approver (= deployment’s pool owner). 
> 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 approver. 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.
>
>
Another alternative to a separate model would be to add a separate state 
to the Deployable model. For approved users, deployments go directly in 
the PENDING state (or is it NEW?) For users that require approval, the 
instances would be placed in the new PENDING_APPROVAL state. THe list of 
UI pending requests would then simply list, for users with the 
above-stated permissions, all Deployments in the PENDING_APPROVAL state.

> 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.
Presumably we'll log the failure reason in the last_error field -- so 
the user will be able to distinguish "admin disallowed" from "approved 
but no matches for launch"

Scott





More information about the aeolus-devel mailing list