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