RFC: Launch requests blocking on approval (#3402)

Jan Provazník jprovazn at redhat.com
Tue Jul 10 12:54:29 UTC 2012


On 07/05/2012 04:27 PM, Scott Seago wrote:
> 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
>
>


Good points, going to update the wiki page, thanks for feedback.

Jan



More information about the aeolus-devel mailing list