I believe it is very contra intuitive to need to install both. In sight of the new pull base job delivery mechanism, I think we can extract the transport provider to a separate package and funcionality, that both of rex and ansible rely on.
Although on foreman side they heavily rely on each other, so we probably should look into that as well.
Yes, It was. But we might be able to find a common code (the ssh and smart proxy send code), that might be better off in some shared gem and thus you would not necessarily need to install REX, if you only want ansible. It would be more sane dependency IMO.
OT: to get REX into core, we should start with foreman-tasks first But I think long-term, REX should be in core, there are many plugins which have some nice features enabled only if REX is present. Which tells me, it should be core functionality.
Perhaps core (both foreman and proxy) should include generic REX capabilities, with the actual providers (ssh, ansible, salt, pull…) as optional plugins that allow you to set up only those methods that you wish to use? Again, long term but probably makes sense to make the clearer boundaries. Then if you don’t have any providers configured, we can hide any ui/settings/etc so it’s invisible to users who don’t use it at all.
What I think we’re missing (on the proxy side) is the split between “provider” (the thing that does the action: smart_proxy_ansible, smart_proxy_rex_ssh) and “transport” (the thing that’s only responsible for the transport: ssh) as both providers will end up doing ssh in one way or another (and rely on common configs, keys, etc).
But then again Ansible and REX-SSH are the only ones sharing a transport?
This is almost exactly the same conclusion some of us working on further pull provider discussions have come to and plan to share very soon. The pull provider proposal RFC would include the support of both the Shell and Ansible “providers” while using a different transport mechanism (MQTT + HTTP).
I’d love the idea of having the common funcionality separate and I’d argue the best place for it is smart-proxy core and foreman core. As I don’t see a reason to have separate project for that. Basically merging REX to core (comon funcionality with simpliest implementation - shell over SSH).
I believe we would need some proper design though, as from all the discussions I don’t think merging REX as-is is the best approach here.