Convert to Juju plugin

[LCVcode]

Certain conventions must be followed for Jockey to become a Juju plugin.

See the Juju docs about managing plugins.

Jockey should be callable with juju jockey.

[johnlettman]

This seems simple enough if I'm reading right:

Juju will automatically search your $PATH for a file named juju-[command], and attempt to execute it with the given [args]. This mechanism is what makes plugins possible.

Perhaps the install target should generate a symbolic link to the executable -- or, should the target executable just have the juju-jockey name?

[johnlettman]

For #32, the diff to generate the static binary with a compatible name would be:

diff --git a/pyproject.toml b/pyproject.toml
index 6175c78..be46401 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -119,7 +119,7 @@ disable-upx = true
 post-build = "hooks.pyinstaller:post_build"

 [tool.poetry-pyinstaller-plugin.scripts]
-jockey = { source = "src/jockey/__main__.py", type = "onefile", bundle = false }
+juju-jockey = { source = "src/jockey/__main__.py", type = "onefile", bundle = false }

 [build-system]
 requires = ["poetry-core"]

[johnlettman]

Slightly pre-mature closing: while it generates a binary following Juju documentation, there's an issue picking it up:

I am following the instructions on creating a plugin for Juju; however, I've been hitting a wall with a snapped plugin:

# which juju-jockey
/snap/bin/juju-jockey

# echo $PATH | grep -o ':/snap/bin:'
:/snap/bin:

# juju jockey --help
ERROR juju: "jockey" is not a juju command. See "juju --help".

Even in the case where it's installed outside of the snap scope, the plugin feature fails to use the program:

# which juju-jockey
/home/jlettman/.cache/pypoetry/virtualenvs/jockey-Msi6Fc7k-py3.10/bin/juju-jockey

# juju jockey --help
ERROR juju: "jockey" is not a juju command. See "juju --help".

I've asked the Juju team for advice here.

[johnlettman]

Juju plugins are broken with the snap for Juju: https://github.com/juju/juju/blob/3.6/snap/snapcraft.yaml#L29

They're using strict confinement.

[johnlettman]

Possible alternative route: https://github.com/juju/juju/blob/52b8f17e45ab17ac31e5d9e5b07ebdd54428e272/snap/snapcraft.yaml#L327-L330

[johnlettman]

Hitting a snag, opened a bug: https://bugs.launchpad.net/juju/+bug/2077486

[johnlettman]

Technically, this is resolved, but the Juju snap is cooked for using plugins. There's no good way to provide the plugin to the Juju snap context because of the strict confinement Juju uses.

Unless Canonical fixes that, there does not seem to be any way to do this for the Juju snap. Otherwise, the raw Juju binary does pick up Jockey.

[LCVcode]

Good point. I will close this issue.

Jockey will function fine as a standalone snap. This makes Juju and Jockey less coupled, so it may make sense to switch from juju-jockey back to jockey.

The way I had imagined Jockey interacting with COS is also affected by this realization. If I understand correctly, all you need to interact with Prometheus is logs. But if Jockey remote options are used, logs would appear on the local machine. Assuming I am understanding things here correctly, I wonder if it would be possible to leave a log on a remote machine when a remote Jockey command is run against that machine.