unclear how to trigger revisions of the application image

Bug #1888645 reported by John A Meinel on 2020-07-23
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

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?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers