Kick off Ansible Playbook from Keystone Actions

[Adam Young]

When a Federated User logs in for the first time, many organizations want to be able to provision resources. This is a specific instance of the general idea that a Keystone token operation should be able to kick off a playbook. Playbooks can perform both OpenStack specific actions such as project create, as well as non-OpenStack issues, such as creating resources in third party systems like LDAP.

[Adam Young (ayoung)]

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.

[Adam Young (ayoung)]

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.

[Lance Bragstad (lbragstad)]

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

[Adam Young (ayoung)]

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.

[Lance Bragstad (lbragstad)]

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).