Project

General

Profile

Actions

Bug #11554

closed

Remote Execution Proxy should be a more formal association

Added by Stephen Benjamin over 8 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

This essentially breaks the idea of isolation, because you can only have one SSH proxy. We must support the ability to have proxies proxies that manage specific hosts. Given two subnets, e.g. a development network and a DMZ, you would have SSH two proxies, and Foreman needs to know which to talk to for which hosts. You can't assume a single SSH proxy can talk to all hosts.

I would suggest that the way it should work is both a Host and a Subnet can have a Remote Execution Proxy, where the host inherits the proxy from the subnet if one is not given.


Related issues 1 (0 open1 closed)

Related to Foreman Remote Execution - Bug #12024: NoMethodError: undefined method `first' for nil:NilClassClosedMarek Hulán10/01/2015Actions
Actions #1

Updated by Stephen Benjamin over 8 years ago

Users are also going to want to pick a particular interface - not necessarily the primary - for the remote execution proxy to talk to, so that adds another layer of complication.

Actions #2

Updated by Ivan Necas over 8 years ago

Are we talking about the mode, when `remote_execution_global_proxy` is truned on or off http://theforeman.org/plugins/foreman_remote_execution/0.0/#4.1Determiningthesmartproxyforhost ?

When the seeting is set to false, it should behave as you described (unless we have a bug in the code), but if I understand it correctly, you've just described what we have written in the manual.

Actions #4

Updated by Stephen Benjamin over 8 years ago

I guess I should RTFM, that's partially it.

The logic doesn't make sense to me though, and I don't think meets my requirement here in this ticket.

Subnets have DNS, DHCP and TFTP proxies, which may all be the same, or maybe all different, with varying levels of connectivity to hosts. The code just picks whatever random one of those has a remote execution provider (e.g. SSH).

There should be a proper Remote Execution Proxy association on the subnet. You might run into the problem where you want a SSH and Salt provider in the same subnet. That could be a has_many association, or a tradeoff we have to accept (one provider per subnet).

Actions #5

Updated by Stephen Benjamin over 8 years ago

  • Subject changed from Only one proxy for a given provider can exist to Remote Execution Proxy should be a more formal association
  • Priority changed from High to Normal

I updated the title a bit since this has been thought about already.

Essentially, the REX proxy should be a first-class association on the Subnet and Host, potentially supporting multiple proxies.

Actions #6

Updated by Ivan Necas over 8 years ago

Yes, I agree on that: the reason for the current behaviour is: it doesn't go against the users at the beginning
(which is IMO important to help users with starting using it), and in many cases, the behaviour will just
work.

Of course, the case you're describing is valid and I'm all for solving that.

Actions #7

Updated by Marek Hulán over 8 years ago

  • Target version set to 85
Actions #8

Updated by Stephen Benjamin over 8 years ago

  • Assignee set to Stephen Benjamin
Actions #9

Updated by The Foreman Bot over 8 years ago

  • Status changed from New to Ready For Testing
  • Pull request https://github.com/theforeman/foreman_remote_execution/pull/33 added
  • Pull request deleted ()
Actions #10

Updated by Anonymous over 8 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100
Actions #11

Updated by Stephen Benjamin over 8 years ago

  • translation missing: en.field_release set to 95
Actions #12

Updated by Marek Hulán over 8 years ago

  • Related to Bug #12024: NoMethodError: undefined method `first' for nil:NilClass added
Actions

Also available in: Atom PDF