juju-run hook/update-status fails on k8s

[Ian Booth]

On a LXD unit, you can do

juju-run hooks/update-status

However, this fails on a k8s unit.

[Harry Pidcock (hpidcock)]

How does this fail on k8s?

[Ian Booth (wallyworld)]

root@mariadb-k8s-0:/var/lib/juju/agents/unit-mariadb-k8s-0/charm# juju-run hooks/update-status
ERROR r.runner.RunCommands: command terminated with exit code 127
root@mariadb-k8s-0:/var/lib/juju/agents/unit-mariadb-k8s-0/charm#

[Ian Booth (wallyworld)]

Seems to be because python is not installed in the workload pod, so it's up to the workload to ensure pythin is there if it wants to run such scripts

[Cory Johns (johnsca)]

Ian, that doesn't make much sense to me. Why would actions (or juju-run) run on the workload pod? Don't they need access to the charm code and hook tools, neither of which would be available on the workload pod?

[Ian Booth (wallyworld)]

actions (to date) are intended to run on the workload, to do things like initiate backups or whatever. For k8s charms, juju copies the charm code and hook commands to the workload pod under /var/lib/juju so this can happen. You can absolutely exec into the workload pod and call juju-run.

If the workload docker image does not have Python or other dependencies installed out of the box, it's up to the charm to provide something like an init container combined with a shared mount point to pull in the required dependencies.

BTW, for the new (experimental) charms acting as k8s operators, actions do run in the charm pod since the charm itself is the workload.

[Ian Booth (wallyworld)]

So it seems that on the operator pod with python3 installed and in the path, juju-run does fail trying to execute an executable Python script or even just juju-run 'python3 -c "print"'

It errors with exit code 127

[Harry Pidcock (hpidcock)]

Using https://github.com/juju/juju/pull/11395 I was able to successfully juju-run python3 after I installed it on mariadb-k8s.

I think https://github.com/juju/juju/pull/11400 fixed this.

[Ian Booth (wallyworld)]

juju--run executes in the workload pod.

This PR
https://github.com/juju/juju/pull/11462

adds the --operator option to allow it to execute in the operator pod.

This provides the same behaviour as for juju run (exec in v3): run by default in the workload pod and provide an option to run in the operator pod.

So you can now exec into either to operator or workload pod and run

juju-run --operator hooks/update-status