Relationship between Ansible and REX proxy plugins

Development
#1

Ohai,

while poking around to get Ansible properly working on Debian, I realized that we have an “unwritten” dependency between the remote_execution_ssh and ansible plugins on the proxy.

The Ansible plugin doesn’t need any of the code from REX, but it relies on some details that are only true when REX is installed:

  • ~foreman-proxy/.ssh is created by REX packaging
  • ~foreman-proxy/.ssh/id_* is created by REX installer
  • users often rely on /ssh/pubkey endpoint to fetch the SSH Key, which is also provided by REX

So I wondered if users who enable Ansible also should automatically get REX-SSH enabled?
Or shall we move that common setup stuff to a more centralized place where both plugins could consume it?

Otherwise users who (today) call the installer with --enable-foreman-plugin-ansible --enable-foreman-proxy-plugin-ansible end up with a setup that cannot run Ansible for them.

#2

I got used to install both, but having the basic configuration separated would be a good idea if it makes installation more simple and reduce overhead.

#3

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.

#4

Wasn’t there some discussion of moving REX into Foreman core (at least on the Foreman side)? We always install REX since so many things benefit from it.

#5

This was done on purpose in the latest versions I think to make it easier to use both options in parallel without doing configuration steps twice.

#6

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.

#7

OT: to get REX into core, we should start with foreman-tasks first :slight_smile: 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.

1 Like
#8

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.

#9

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?

RFC: REX pull provider
#10

I think Salt can use SSH, too. But @Bernhard_Suttner or @quba42 will very likely know this better as ATIX is more into Salt.

#11

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

1 Like
#12

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.

1 Like
#13

Why not? You mean the transport vs provider change should happen before that merge? Or is that something else you’re aware of?

1 Like