Move REX ssh key management into separate class

[wbclark]

No description provided.

[ekohl]

This looks ok to me. You can add a spec test:

require 'spec_helper'

describe 'foreman_proxy::plugin::remote_execution::ssh::keys' do
  it { is_expected.to compile.with_all_deps }
end

Since it doesn't use facts in anyway, I'd say that's good enough for testing.

It does make me wonder: should the name be tied to REX? Just thinking about the future case where Ansible might also need SSH keys but REX is configured to use MQTT.

[wbclark]

It does make me wonder: should the name be tied to REX? Just thinking about the future case where Ansible might also need SSH keys but REX is configured to use MQTT.

It's concerning to me too. After staring at it for a bit I don't see a clean way to fix this without breaking some interfaces.

[ehelms]

It does make me wonder: should the name be tied to REX? Just thinking about the future case where Ansible might also need SSH keys but REX is configured to use MQTT.

Ansible is REX in our ecosystem. And by that I mean, REX is the umbrella and it has sub-functionality underneath that falls into transports and providers. SSH, http and mqtt being transports, and Scripts and Ansible being providers (or languages) that can be used. It all rolls up to REX though.

[wbclark]

It does make me wonder: should the name be tied to REX? Just thinking about the future case where Ansible might also need SSH keys but REX is configured to use MQTT.

Ansible is REX in our ecosystem. And by that I mean, REX is the umbrella and it has sub-functionality underneath that falls into transports and providers. SSH, http and mqtt being transports, and Scripts and Ansible being providers (or languages) that can be used. It all rolls up to REX though.

This commit cleared things up for me theforeman/smart_proxy_ansible@3f408b6

Therefore, I think this PR is in a mergeable state unless @ekohl has other feedback?

[ehelms]

@ekohl could you take a final look as well