Add charm metadata for 'juju run-action' on the operator pod

[John A Meinel]

At least as far as I can tell, you can't do:

  juju run-action --operator

We do support 'juju run --operator'. There are use cases for getting information from the state that the charm is acting on, not just the state that the application is operating on.

(sorry about the earlier confusion around juju-v3 feature flag, that isn't actually relevant here.)

[Ian Booth (wallyworld)]

actions that are for k8s operator charms (you need to turn on the k8s-operators feature flag to use this capability) automatically run actions on the charm pod as there is no separate workload.

But yes, actions currently only run on the workload pod as the expectation was that the semantics would be similar to vm deployments; actions are operations on the workload.

Do we have any use cases that we don't yet satisfy either of the above scenarios?

[Ian Booth (wallyworld)]

We discussed adding additional action metadata to signal that an action needs to be run on the operator pod - this is a charm author responsibility, not the end user of the charm. Hence the --operator flag on juju run-action doesn't really make sense. Moving to 2.8.1 but might get pushed out to 2.9

[Tim Penhey (thumper)]

I'm going to suggest we hold off on all this for now as we are in at state of flux around the architecture of the juju unit w.r.t. k8s. We don't want to do work that we'll have to undo.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.