Open ktdreyer opened 5 years ago
Ansible includes "connection" plugins that might help here. I have not looked into this in depth, but one that looks interesting is "httpapi". Maybe we need a "koji" connection plugin.
https://github.com/network-automation/httpapi/blob/master/playbook.yml is one example of using httpapi.
"httpapi" looks a bit too specific for Cisco/network devices.
However, this post describes how to create a custom connection plugin that caches a login credential: https://steampunk.si/blog/let-us-give-ansible-a-rest/ .
When we use a connection plugin, all the Koji client traffic originates from the host that runs Ansible. Right now we have some users that run the koji-ansible modules on remote nodes (via Ansible's usual SSH mechanism), and some other users running koji-ansible in containers, so we need to evaluate how to make this work in all cases.
One project to watch here is the new Ansible "turbo" module. There was a presentation at AnsibleFest 2020. A bit unclear how widespread and battle-tested that is at this point, but an interesting approach to caching.
Currently every Ansible module authenticates its own unique Koji client session. This means we always send the login RPC to Koij Hub every time we want to make a change.
This is not slower than invoking the koji CLI many times, but we may be able to do better.
When we do a client login to the Koji Hub at the
/ssllogin
endpoint, we get back a XML-RPC response with asession-id
(int) and asession-key
(string). Example:The Koji client then uses these two values to authenticate all the requests going forward. Subsequent HTTP requests for XML-RPC look like this:
where
callnum
is an integer that increases for every authenticated call.In koji-ansible, we could return
session-id
,session-key
, from akoji_login
module, and have all the other modules use these variables if they are defined for the profile.Note, we would also need to cache
callnum
in a way that every other koji-ansible module can increment it.