Just notes:

• provisioning callbacks use the host's inventory membership for functional reasons (--limit on the template), as well as to certify it's an allowed machine
• workflows can consist of 20 JTs that each have a different inventory which would then mean. ¯_(ツ)_/¯ in terms of determining that membership

Hence, this would likely have to be tied to the context of 'this workflow uses one and only one inventory for all component job templates' for us to allow it. Otherwise, it doesn't really make sense.

I'd be fine with requiring a single inventory for this function. but i think the functionality is greatly needed. At current it requires to run some squirrely looking curl commands(and add functions to make sure each job finishes before the next one goes off) to get the same functionality. It would be cleaner and better for me to be able to call a pre-made workflow.

I understand the reduction in range of options for WFs by limiting each sub JT to single inventory, specified at WF launch (or schedule). However, I believe there are more valuable use cases for a single inventory per WF.
We'd love to see this implemented.

Adding my voice as well....would love to see this feature.

Does this change also impact being able to pre-select the "prompt on launch" elements when scheduling a job?

Does this change also impact being able to pre-select the "prompt on launch" elements when scheduling a job?

That's already included.

Any updates on this?

+1

Just notes:

• provisioning callbacks use the host's inventory membership for functional reasons (--limit on the template), as well as to certify it's an allowd machine
• workflows can consist of 20 JTs that each have a different inventory which would then mean. ¯_(ツ)_/¯ in terms of determining that membership

Hence, this would likely have to be tied to the context of 'this workflow uses one and only one inventory for all component job templates' for us to allow it. Otherwise, it doesn't really make sense.

Hi, for your first comment about allowed machine. This is something users will take care and you shoulld not be concerned about allowed machine. Whole point of calling provisioning callback is without passwords for trusted machines. We are making sure only trusted machines are calling this. So, whether JTs refer to same inventory or different, should not be on any concern in providing the feature.

While I understand that you may be blocking the API in your environment to ensure only trusted machines are calling it, we still need to do that verification on the AWX side to avoid issues in general deployments.

Thoughts on the UI work needed to get this done:

1. Add ALLOW PROVISIONING CALLBACKS checkbox to workflow form. Should this checkbox only be shown when the user has a wf level inventory set and/or prompt for inv on launch? What if all of their JT's already use the same inventory? Might be best to just always show it.
2. When the user toggles the above checkbox on, two more fields are exposed: PROVISIONING CALLBACK URL and HOST KEY CONFIG. I believe these two fields would behave the same way they do for JT callbacks.
3. When launching a WFJT with callbacks enabled it sounds like the api might error out if all templates don't use the same inventory. The UI will need to handle this error.
4. The UI may want to indicate to the user that callbacks have been enabled while editing the workflow graph itself. In the node form we show messages describing the inventory override hierarchy when a wf level inventory is provided. We may want to do something similar when callbacks are enabled to make sure that the user understands that all templates must use the same inventory for callbacks to work.

I suspect this is better restricted to workflows that have a workflow-level inventory defined, rather than individually assessing each template in the workflow.

👍

Additional thoughts/feedback:

1. Recommend to always show it, perhaps with a mouse over tip that it has specific requirements and link to doc?
2. Sounds good, would be good to keep it consistent between WFJT and JT of course.
   3/4. Agree, again referencing docs would be good as potentially complex requirements|feature. Also, to avoid errors/problems couldn't we force inheritence of inventory field from WFJT down to children (regardless of JT prompt check status) when callback WFJT enabled rather than perform requirements validation against children. Only occurs when callback enabled WFJT executed, not when child JT's executed independent (of course). Pushing requirements such as this inventory field down to children based on feature selection at WFJT level would streamline the user experience of WFJT level inheritence and avoid the need to enable 'prompt' on every child.. Perhaps could add 'force WFJT inheritence' check to relevent fields to control the ability to force push to children.

• Adds substantial extension to provisioning use case, e.g. when using complex | nested workflows.

Thoughts on the UI work needed to get this done:

1. Add ALLOW PROVISIONING CALLBACKS checkbox to workflow form.  Should this checkbox only be shown when the user has a wf level inventory set and/or prompt for inv on launch?  What if all of their JT's already use the same inventory?  Might be best to just always show it.

2. When the user toggles the above checkbox on, two more fields are exposed: PROVISIONING CALLBACK URL and HOST KEY CONFIG.  I believe these two fields would behave the same way they do for JT callbacks.

3. When launching a WFJT with callbacks enabled it sounds like the api might error out if all templates don't use the same inventory.  The UI will need to handle this error.

4. The UI may want to indicate to the user that callbacks have been enabled while editing the workflow graph itself.  In the node form we show messages describing the inventory override hierarchy when a wf level inventory is provided.  We may want to do something similar when callbacks are enabled to make sure that the user understands that all templates must use the same inventory for callbacks to work.

I just wanted to add some feedback to say this would be very useful. We were looking into this for the same reason as the referenced use case, splitting up our provisioning playbook into smaller chunks. It would be a helpful feature to have.

A friendly chime-in from an Linux Enterprise Engineer:
PCB for WF would be extremely useful right now.

After a year with Tower, its hard to imagine living without it.
It is the clean, superior product that I had imagined.
(Smartest thing we did it? We named our JTs based on hierarchical tags, left to right. You know what every JT does at a glance.)

Provision-callbacks are a lighting fast way integrate Tower-Automation with other Automation-processes, ex. Service-Now requests, and Teraform for cloud-automation-integration.

Here is where the speed gets multiplied:
We designed our JTs to be plugable modules.
PCBs will extend that use to anything that we want to call our WKs/JTs (in the order that we require.)

This allows us to re-use and extend our JTs.
PCB for Workflow will actually help us solidify a Cloud-Agnostic stance, by removing complex workflows from the cloud provider, and allow us to centrally manage those workflows in Tower, instead of being embedded in the cloud-provider.

Relying on yaml code to link JTs is doing an end-run around Tower's foundational purpose, defying it's essence, and defying the modular approach to writing JTs that makes it possible.

The limitation to one inventory per WF is completely understandable, and acceptable.

A further (maybe simple ?) enhancement to WF logic would be to use variables instead of run-on success/fail logic.
(ie. run template 6 when "run6" var is present.)
This allows you to pick your JTs with extra vars that you insert into the beginning of the WK.

However, the PCB for WK is far and above the more useful of the two.

Thanks for listening, and rock on.

@wenottingham is this a near-term priority that we should track more closely as an enhancement in the next major release?

Do we have this PCB option for WT in latest release ?

+1

+1, please this would be really great to have a set of templates, all using one inventory, that can be run with ONE url callback

+1