Ugrading charms from different clients

juju
1

When reading “juju upgade-charm --help” I came across this sentence:

Deploying from a path is intended to suit the workflow of a charm author working on a single client machine; use of this deployment method from multiple clients is not supported and may lead to confusing behaviour. Each local charm gets uploaded with the revision specified in the charm, if possible, otherwise it gets a unique revision (highest in state + 1).

use of this deployment method from multiple clients is not supported and may lead to confusing behaviour.

This is problematic.

Imagine if you have a set of “private-local” charms which your team (such as ours) is using and charmhub is not available or an option.

Your team might be sharing code, but any two developers may not deploy to a model, using the same code since the “juju upgrade-charm” will only work from a single client!

I don’t recall myself hitting this issue myself yet, but we have a strange issue at the moment with “juju upgrade-charm”, which we are pursuing.

  • Is the statement “use of this deployment method from multiple clients is not supported and may lead to confusing behaviour.” true?
  • What would the effects be of deploying a “local” charm build on a different clients?
2

The issue has historically been with the locally generated revision number, the sequence of which is unique to each client.

Local charms do support reading a “revision” file from the root directory, where the file contains a single line with a revision number to seed the initial revision. This could be ok for initial deployment, if the revison file were incremented each time a commit is made and people pull the latest source before deploying etc. However, you lose tracking each time the charm is refreshed from the source directory using “juju refresh app --path /path/to/charm”; the revision number in the juju model is incremented but the revision file on disk stays the same.

If the charm is a checked out git repo, the the current sha is uploaded and stored in the model so that juju status --format yaml can display it, allowing you to use this to identify the provenance of the deployed charm rather than a revision number.

So with these limitations in mind, it work so long as you understand the issues and how your workflow could be set up to track the source of a deployed charm’s code etc.

1 Like
3

FYI: There is a bug report created regarding this.