How can I make sure that my charm pulled to associated resource revision

juju
1

I have been developing and iterating over a k8s charm and its container (a resource). The charm was published on charmhub along with the resources. During development, I was releasing a new revision of my charm along with the resource (associating the charm release with the new revision).

At the time of deploying the new charm, I noticed quite often that the new (and associated) resource was not pulled. Instead, the charm was installing and running with a previously installed (and incompatible) resource.

I noticed that by installing my charm from charmhub, but also when installing from a local charm (with the resource from a registry).

This is causing huge instability in my deployments, and I was wondering if this is an expected behaviour or if there is a way to enforce the charm to install and pull the associated resource.

Thank you.

2

did you double-check that the resource has been indeed correctly uploaded?

What does charmcraft status your-charm say? Is the correct resource revision associated with the correct charm revision?

As far as I know the only way you can ‘enforce’ that a given resource is deployed with your charm is do juju deploy ... --resource foo=./your-resource-file.yaml

but you can’t, say, pass a --resource-revision-tag=r42

3

Yes I double-checked that the resource was correctly uploaded and associated to the charm (in fact I had two VMs, one freshly deployed with the correct version and one old that had a previous version of the charm installed, and the resource was not getting updated when updating the charm). The juju status command is returning that the status is active, workload active, agent idle and is returning the correct version of the charm revision. Additionally, the kubectl describe pod my-unit was showing the old container sha256.

Enforcing the specific overlay in the bundle or the overlay works, but then it means updating the bundle manually every time.

Is it normal that juju can pull a new charm without pulling the new associated resource?

4

It feels weird, but it may be expected if you’re doing a refresh.

5

In my case I was removing the application with juju remove-application --force my-app and redeploying the application with juju deploy

6

do be aware that --force might leave resources lingering around. Try without and let’s see if it persists :slight_smile:

7

Thanks, that might be the reason then. I always use --force when deleting my applications, otherwise it takes too long. I will try without!

8

I also tend to do it :blush: then I take care to not recycle model and app names and things seem to work okay in development

9

I confirm that removing without the --force flag solves the issue!

1 Like