On 07/04/2012 07:25 AM, Jan Provaznik wrote:
> Hi,
> draft is on wiki:
>
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Launch_request...
>
>
> 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