Teleportation with portals (local and remote Juju)

[johnlettman]

We could make a significant change to Jockey by adding remote connectivity support. I have encountered success with this in my CVE collection tool here:

https://github.com/johnlettman/jujucvetool/blob/c9ad67ffb43808f40e4bed91f60e86b59d329724/src/jujucvetool/cloud.py#L27-L40

As Jockey currently operates, the change nominally selects local, which only runs commands locally. Implementing the same functionality would only change the existing commands if a remote host is specified. In addition, I was able to handle environments where one needs to assume the role of a different user over SSH to execute Juju commands (e.g., sudo su - jujuadmin):

https://github.com/johnlettman/jujucvetool/blob/c9ad67ffb43808f40e4bed91f60e86b59d329724/src/jujucvetool/cloud.py#L55-L66

In summary, this provides:

• remote Juju, no sudo
• remote Juju, sudo as someone else
• local Juju, no sudo
• local Juju, sudo as someone else

... all transparently through the same functions.

This would have interesting implications for specific users who manage many Juju environments across many networks. The tool I am referencing has terrible controller and model selection, but the local/remote functionality seems solid and worth extracting.

[johnlettman]

I'll leave that to your decision, @LCVcode, but I will self-assign if you give the green light to implement that functionality.

[LCVcode]

This functionality sounds interesting. Can you give me an example use case? I don't think it would be hard to convince me to give this a +1.

Would it be something like juju-jockey --remote jujuadmin@remote.com units?

[johnlettman]

It's currently in PR #47 but, it looks like this:

juju-jockey --host bastion.site.local --user jlettman --sudo jujuadmin units name~controller

or shorthand:

juju-jockey -H bastion.site.local -U jlettman -S jujuadmin units name~controller

All of them should respect: JUJU_CONTROLLER and JUJU_MODEL environment variables, falling back to juju whoami. This is useful for places that might source shell variables to switch around between models. :-)

[LCVcode]

This sounds like a good feature to me.

How would subsequent calls to the same remote juju cluster perform? I assume that, under the hood, there is an ssh connection established with each juju-jockey remote command. Therefore, each command would see a delay to establish said connection. Short of caching remote juju statuses locally, which I definitely do not want to do (at least not by default), might there be a way to keep a session alive across multiple juju-jockey commands?

[johnlettman]

This sounds like a good feature to me.

How would subsequent calls to the same remote juju cluster perform? I assume that, under the hood, there is an ssh connection established with each juju-jockey remote command. Therefore, each command would see a delay to establish said connection.

They perform reasonably well; however, they all share a single channel. The SSH connection is only explicitly closed with close(), but it will be reused in the meantime.

Short of caching remote juju statuses locally

In my PR, the file cache does store the status, but it is unique to the following keys:

• hostname/IP
• controller
• model

which I definitely do not want to do (at least not by default)

Ope! This could be made tunable.