Kick off Ansible Playbook from Keystone Actions

This could be tied in with the notifications framework without having a remote call out to the process that kicks off the Ansible task. That said, the Ansible playbook should be async so the Keystone process can continue and can return a value to the end user prior to the end of the playbook.

Since ansible does not have a listening architecture, the flow would have to start with spinning up worker process to listen to notifications. That process could be on a separate machine from the Keystone server.

Alternatively, since AWX is now open source, we could spin up a full AWX instance and have it listen for Keystone events. That is a fairly Heavy weight solution, but it probably makes sense for production workflows. The AWX and Keystone servers need to share a common view of RBAC. Since AWX has its own RBAC structure, we should compare that to the Keystone one to see how it aligns.

This sounds partially related to the shadow mapping work, or auto-provisioning [0], which seems to address the first example in the description. What would be a more specific example of the second case with LDAP?

Also - I tend to agree this would be something best suited for the notification system. In that case, there wouldn't be anything to do in keystone would there?

[0] https://docs.openstack.org/keystone/latest/advanced-topics/federation/federated_identity.html#auto-provisioning

The only problem with saying it is pure notifications is that it requires an active process to kick it off. In cases where there is no full workflow engine, the users will not have the ability to manage these tasks. Having something in-process with Keystone but triggered from a notification would be a middle ground.

I think the notification route makes the approach more generic, instead of something in-process with keystone that might end up specific to a certain tooling (e.g. Ansible).