unclear how to trigger revisions of the application image

[John A Meinel]

As far as I can tell, the way the image to run is defined is just the string from from config['image'].
However that is just 'jenkins-agent-operator' with no clear definition of a point in time or an exact binary that should be run.
Which means that if I do "juju deploy jenkins-agent.charm" today, and then do it tomorrow, I may get a different application image. Even further, if K8s just decides to reschedule the agent pod (say node 1 is dying, so it reschedules to node 2), then during the rescheduling if node 2 didn't already have an image cached for 'jenkins-agent-operator' it will download whatever the current tag content is, which means you can end up with heterogenous deployments.
It also is unclear how you would trigger K8s to roll out an update that you want it to have, since everything is just referenced by its label.

It is also odd to name the *application* pod '*-operator'. The Operator pod is the 'hypervisor' of the running application (which is where the Charm code runs). But the actual application pod certainly shouldn't be considered an -operator, should it?

[Tom Haddon (mthaddon)]

The default image has been updated to "jenkinscicharmers/jenkinsagent:edge". This is built from an OCI Recipe on Launchpad. There isn't currently a way to tag those images differently in an automated way (see https://bugs.launchpad.net/launchpad/+bug/1897813) but when that's available, or there's a different approach here, we'll update things to use a more specific revision.

The user is still free to set that image to be whatever they want as well of course.