Manually triggering juju events

[mthaddon (Tom Haddon)]

Hi,

We’re writing some documentation on upgrading a charm from a pod-spec version to the sidecar version. Unfortunately the pod-spec version was using StoredState without use_juju_for_storage=True, and the DB relation’s info is stored there, so when you upgrade currently the charm can’t find that data in StoredState (this is another good cautionary tale as to why using StoredState can catch you out). One option here is to break the relation and recreate it, but I’d like to know if it’s possible to simply trigger the relevant event manually.

Here’s the relevant part of show-unit (local deployment, so passwords are okay to show here):

discourse-k8s/0:
  opened-ports: []
  charm: ch:amd64/focal/discourse-k8s-8
  leader: true
  life: alive
  relation-info:
  - relation-id: 1
    endpoint: db
    related-endpoint: db-admin
    application-data:
      allowed-subnets: 10.152.183.161/32
      allowed-units: discourse-k8s/0
      database: discourse-k8s
      host: 10.152.183.105
      master: dbname=discourse-k8s fallback_application_name=discourse-k8s host=10.152.183.105
        password=ytqjVHPrdNPwPYH6zBpj4mJmf754w6hxRwmbPrpy port=5432 user=discourse-k8s
      password: ytqjVHPrdNPwPYH6zBpj4mJmf754w6hxRwmbPrpy
      port: "5432"
      standbys: dbname=discourse-k8s fallback_application_name=discourse-k8s host=10.152.183.206
        password=ytqjVHPrdNPwPYH6zBpj4mJmf754w6hxRwmbPrpy port=5432 user=discourse-k8s
      state: master
      user: discourse-k8s
      version: "12"
    related-units:
      postgresql-k8s/0:
        in-scope: true
        data:
          allowed-subnets: 10.152.183.161/32
          allowed-units: discourse-k8s/0
          database: discourse-k8s
          host: 10.152.183.105
          master: dbname=discourse-k8s fallback_application_name=discourse-k8s host=10.152.183.105
            password=ytqjVHPrdNPwPYH6zBpj4mJmf754w6hxRwmbPrpy port=5432 user=discourse-k8s
          password: ytqjVHPrdNPwPYH6zBpj4mJmf754w6hxRwmbPrpy
          port: "5432"
          standbys: dbname=discourse-k8s fallback_application_name=discourse-k8s host=10.152.183.206
            password=ytqjVHPrdNPwPYH6zBpj4mJmf754w6hxRwmbPrpy port=5432 user=discourse-k8s
          state: master
          user: discourse-k8s
          version: "12"

I’ve been trying the following, based on some code I’ve seen in another charm:

juju run --unit discourse-k8s/0 "JUJU_RELATION=db JUJU_RELATION_ID=1 JUJU_DISPATCH_PATH=db-relation-joined timeout 1200 ./dispatch"

If I tried this without JUJU_RELATION or JUJU_RELATION_ID I get an error in juju debug-log, but if I include them both I don’t see any relevant output in debug-log and the event doesn’t seem to be triggered.

Does anyone know what I’m missing here?

Thanks, Tom

[ppasotti (Pietro Pasotti)]

Does this help?

Simulating events in live units

[excerpt of a community workshop @ 16 sept 2022] When the juju agent decides it’s time to execute the charm, the dispatch script is ran with a certain environment. ops translates bits and pieces of that environment into an Event object, which the charm can use to reason about why the charm code itself is being executed; e.g. this remote unit touched its relation data my config changed the user ran an action … When developing or debugging a charm, it is often useful to make subtle changes to …

look into jhack fire

[mthaddon (Tom Haddon)]

Thx, will take a look at that!