-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Add a pause with approval to continue between playbooks in workflow job #1206
Comments
This is not something we would likely get to in the near future, but it has been requested a few times, including:
|
Note that the best workaround for this case is using |
This is much needed feature. The workaround which you are suggesting wait_for, cannot be used in our case. Operations users in our company only have UI access and they are not allowed to login into CLI and set some flag in any way. |
wait_for and get_url don't require local CLI accesss, they can check ports on remote machines ( |
I second @ghost, this feature would be really useful. I was thinking that maybe, rather than having this "Approval feature" as a Workflow feature only, having it placed at the Job Template level would be a better idea because it could be used for each node of a Workflow and for single Job Template too. Added to the already available job scheduling features, it would really increase the usefulness of the project, according to me. |
This is most likely going to involve:
----- Future ----- ?
|
@matburt unless the approval step is an actual task with certain parameters |
Thoughts on UI impact: Workflow Editor
Question: Can you have more than one Jobs List
Question: Should the act of resuming/approving a job take the user to the workflow results page or leave them on the current page? My View Jobs List
Workflow Results
Question: Do we ever see a situation/need arising whereby a user could establish a I could see an argument being made for providing our users with a more streamlined view of |
This is tricky, because in order for this to work on a standard job template the approval/disapproval would have to be associated with the job itself. If we carry that forward into Workflows it would cause the user to have to create a stub job to act as the approval step, but for notifications it would give us something to hang a notification onto. We could go a different way with this entirely, which I think is what the original proposal is asking for anyway, and require that approvals use a workflow even if they are just looking to run a single job. This is what I'm leaning towards now. The approval node then becomes another node type of Given this, you could have as many of these as you want, anywhere in your Workflow. A Workflow overall could also include a timeout value where workflows don't hangout forever... that they eventually expire if no one comes along to approve it. Given that we'd do this entirely from workflows, it could appear as something distinctive within the Workflow detail view indicating which node needs approval. My intuition is that this will also need some sort of indicator on the Job list view (where we indicate which Workflows are waiting on approval). Probably also from the Dashboard?
I alluded to this up above, but I could see doing something like this. I think my proposed architecture here would support this in the future without us having to implement anything specific right now. RBAC |
Yeah, I'm fine with this being just for a workflow node, and if you want it for a single JT, create a workflow with it. For RBAC, etc. a MVP would be two choices - '"approve by anyone who can execute", and "approve by org admin or above". We could consider other choices, but I don't think we need them initially. |
Yep. I think Org Admin or higher would work here. |
|
|
From an API perspective there will be some way to get a list of nodes that are awaiting approval |
Proposed UI changes (this likely isn't the final iteration): Creating a pause node in a workflow job template
Approving/denying continued execution
Jobs List
Workflow Results
Activity Stream
|
Discussed some API implementation with @chrismeyersfsu and @beeankha. Here are the high level notes, @mabashian @kdelee this may interest you.
This means we'll be adding some new APIs. Specifically:
These endpoints will allow you to create and edit new approval templates. As we progress in feature development, we'll hang specific features/attributes off of these endpoints, such as "the notification templates for this approval template" or "who can approve".
@mabashian I expect these endpoints will be useful for "fetching a list of pending approvals" i.e.,
Additionally, the UI can use special We'll need to work out and answer some questions related to RBAC. Specifically:
|
Hi @spsingh1982 , we don’t have an exact ETA for when this will be released as part of AWX, but it is something we're currently working on. You can take a look at the work-in-progress PR here: #4264 |
@beeankha @mabashian @chrismeyersfsu @AlanCoding, After much deliberation, I think this is what we're currently settled on (if I can summarize). There will not be a global To create a new pause node, you do:
This means that the only way you can create an approval template is via this endpoint, where it's assigned to a node. We will continue to have |
@dsesami and I brought up that it looks like we need a Additionally this would be used when a approval node fails due to time out as the text field where tower puts in |
I also had the thought that there should be another way to know that a workflow is in a pending state; in the running jobs list, it would be nice to highlight the pending workflow in some manner to signal that action needs to be taken. cc @mabashian |
@kdelee and I are also wondering how users will review previously approved/denied jobs from the past + view the Seems like clicking on the approval node from the workflow should just take us to a job detail view, just no stdout. Basically it'd be this page, but no stdout block (if hiding the element is difficult for some reason, then just leave it blank maybe?) and then just dropping all the extra vars and just having a few key ones here. The fields might be something like
|
A pile of questions:
|
I think our intention is to use the activity stream to record approve/deny, since it already has a lot of the attributes we care about. |
In a recent chat about this, I think we decided to not show approval jobs in the global job list, because the implications of calculating their RBAC (can this be approved by the current user) in the context of the global unified job list worried us from a query performance perspective cc @AlanCoding @matburt. |
@beeankha or @AlanCoding, Could one of you summarize some answers here for @kdelee re: the new |
I think we had a very clear answer to this, and the implementation has already begun. Organizations get a new (this assumes the existing parentage structure is obvious to you, workflows live inside an organization, and the nodes live inside a workflow) |
@ryanpetrello I would argue that this scenario is the exact thing that it's needed for. It should say something like (assuming they can see the WF in the first place) "This workflow is in a pending state until someone with permissions approves it". Basically, IT or whomever can then ask the approver to push the job forward. At least, that's what I'm imagining, feel free to correct me if I'm missing something though |
There are two proposals I worry are getting confused here:
We decided against showing approval jobs in the list. They have a confusing role (duplicated with the workflow job), and have their own separate place in the UI.
It's more nuanced than that. The workflow job is in the "running" state if an approval job inside of it is in the "pending" state. Also, the blocking by an approval job is specific to 1 branch, so other branches may have running jobs simultaneously. It is valuable information to the user to see that a workflow job is waiting on 1 or more approvals. I just don't know if showing this in the UI JOBS list is in scope for the initial version of the feature. |
my main concern is that a user might just see the "running" state on the workflow itself, not see a notification that an approval is pending, and just leave it without knowing something is needed. as long as the pending approval list is marked clearly enough, I'm ok with that. |
@dsesami one of the things we're adding with this feature is a new item in the top nav that displays pending approvals: In the first pass of this feature, we're not planning on showing these approvals as distinct jobs in the global jobs list. |
That works for me. |
Sorry, I've briefly checked current development progress. Will there be a descriptive message/or jinja template based message that will show current state of workflow, so that reviewer will approve specific actions that will be performed? I.e. configuration diff, or dynamic values calculated to that stage. |
@ryanpetrello so answer to "Will the approval node in the workflow job view link to anything with a |
@kdelee we haven't planned any UX interaction where you go view an approval job in the UI on a separate page the way you do job results. Our plan is to have a global notification list where you can view the list of pending approvals and (if you have permissions) approve or deny them. We'll likely make it so that when you're viewing a workflow that has a pause node, you can also approve/deny it there (if you have permission): |
Also, the If the node times out, |
Not in this version. There's no real mechanism to pass arbitrary data in this way to show the user other than maybe showing |
This feature has been merged. PR: #4264 |
ISSUE TYPE
COMPONENT NAME
SUMMARY
I am requesting a pause feature be included as one of the steps in a job workflow in-between playbooks so that a user can give the +1 to continue on to the next playbook in the job workflow.
This will give the user the unlimited amount of time they need to do their manual steps, but also allow them to continue as fast as they are ready with out having to wait on some other trigger.
The text was updated successfully, but these errors were encountered: