Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider reinstating --gateway in v2 somehow #1806

Open
bitprophet opened this issue Jun 19, 2018 · 1 comment
Open

Consider reinstating --gateway in v2 somehow #1806

bitprophet opened this issue Jun 19, 2018 · 1 comment

Comments

@bitprophet
Copy link
Member

@bitprophet bitprophet commented Jun 19, 2018

In v1, the --gateway CLI option set env.gateway to a host string, which triggered use of a ProxyJump/direct-tcpip style gateway.

In v2, the gateway config option gets used as a default value for Connection(xxx, gateway=yyy), which can be either a string (triggering ProxyCommand style gatewaying) or another Connection (triggering ProxyJump style gatewaying).

What this means is that v2 lost the ability to specify a ProxyJump style gateway at runtime; the only current possibility is to do eg INVOKE_GATEWAY="ssh foobar" fab mytask (or any other Fabric 2 bearing Python program), which can only set a string because that's how env vars tend to work, and thus can only be used for ProxyCommand style gatewaying.


It'd be nice to address this, but doing so does require leaning more heavily on string-to-object shorthand. We do retain that to some degree (the first arg to Connection can resemble v1 host strings) so it's possible, just not 100% ideal.

More importantly is just the split between the two gateway styles; if we want to do this properly we need two CLI flags so we can tell exactly what the user intends, otherwise it's ambiguous ("ok, we parsed the CLI, and we have a gateway string. should we be trying to make a Connection out of it or no?").


FWIW - given we have SSH config support and other strong (including Python-format) configuration file support, and that one's need to use a gateway is usually not something that changes minute to minute, this feels low priority to me considering it's a nontrivial bit of work and extra CLI args. So I'm not putting it in any milestones yet.

@jalaziz
Copy link

@jalaziz jalaziz commented May 13, 2020

We're in the process of upgrading to Fabric 2.x and we hit this issue. We're trying to work around the issue or patch in support for ProxyJump style gatewaying va the CLI.

Just thought I'd leave a note here since it's documented as something you might consider adding if users actually notice the lack of the feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.